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FOREWORD 


This  technical  report  covers  work  performed  under  Air  Force 
Contract  F33600-87-C-0464,  DAPro  Project.  This  contract  is 
sponsored  by  the  Manufacturing  Technology  Directorate,  Air  Force 
Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio.  It  was 
administered  under  the  technical  direction  of  Mr.  Bruce  A. 
Rasmussen,  Branch  Chief,  Integration  Technology  Division, 
Manufacturing  Technology  Directorate,  through  Mr.  David  L.  Judson, 
Project  Manager.  The  Prime  Contractor  was  Integration  Technology 
Services,  Software  Programs  Division,  of  the  Control  Data 
Corporation,  Dayton,  Ohio,  under  the  direction  of  Mr.  W.  A. 
Osborne.  The  DAPro  Project  Manager  for  Control  Data  Corporation 
was  Mr.  Jimmy  P.  Maxwell. 

The  DAPro  project  was  created  to  continue  the  development,  test, 
and  demonstration  of  the  Integrated  Information  Support  System 
(IISS) .  The  IISS  technology  work  comprises  enhancements  to  IISS 
software  and  the  establishment  and  operation  of  IISS  test  bed 
hardware  and  communications  for  developers  and  users. 

The  following  list  names  the  Control  Data  Corporation 
subcontractors  and  their  contributing  activities: 


SUBCONTRACTOR 

Control  Data  Corporation 


D.  Appleton  Company 


CNTEK 


Simpact  Corporation 


Structural  Dynamics 
Research  Corporation 


Arizona  State  University 


ROLE 

Responsible  for  the  overall  Common 
Data  Model  design  development  and 
implementation,  IISS  integration  and 
test,  and  technology  transfer  of  IISS. 

Responsible  for  providing  software 
information  services  for  the  Common 
Data  Model  and  IDEFIX  integration 
methodology. 

Responsible  for  defining  and  testing  a 
representative  integrated  system  base 
in  Artificial  Intelligence  techniques 
to  establish  fitness  for  use. 

Responsible  for  Communication 
development . 

Responsible  for  User  Interfaces, 
Virtual  Terminal  Interface, and  Network 
Transaction  Manager  design, 
development,  implementation,  and 
support . 

Responsible  for  test  bed  operations 
and  support . 
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SECTION  \ 
INTRODUCTION 


1.1  Back^ound 

In  September  1989,  Control  Data  awarded  subcontracts  to  IBM  Corporation  and  Northrop 
Corporation  for  the  Enterprise  Integration  Framework  task.  This  document  presents,  as  an 
unedited  appendix,  the  final  report  of  the  Northrop  effort.  DAPro  document  EIF  620350002 
provides  the  IBM  Workshop  Briefing. 

1.2  Di.sclaimer 

The  conclusions  presented  by  this  document  are  those  of  the  Nonhrop  EIF  Team  and  do 
not  necessarily  reflect  those  of  either  Control  Data  or  WRDC/MTI.  The  release  of  this  document 
does  not  imply  endorsement  by  the  USAF. 
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SECTION  2 
EIF  OBJECTIVES 


2.1  WRDC/MTI  Statement  of  Work 

In  June  1990,  WRDC/MTI  released  a  SOW  defining  the  Enterprise  Integration  Framework 
task.  A  simplified  version  of  that  SOW  is  presented  in  this  section. 

2.1.1  Background 

The  Integration  Technology  Division  of  WRDC/MTI  and  their  cosponsors  will  be  leading 
an  effort  to  define,  develop,  and  validate  through  implementations  a  national  framework  for  inter 
and  intra  enterprise  integration  based  on  open  systems  and  national  and  international  standards. 
This  effort  will  be  cosponsored  by  the  Defense  Manufacturing  Office  of  the  Defense  Advanced 
Research  Projects  Agency  (DARPA  DMO),  the  Computer  Aided  Acquisition  and  Logistics  Suppon 
(CALS)  office  in  the  Office  of  the  Secretary  of  Defense  (OSD  CALS),  and  the  National  Institute 
for  Standards  and  Technology  (NIST).  This  effon  will  begin  with  a  preliminary  strawman 
framework  development  task  to  serve  as  the  catalyst  for  national  debate  and  involvement  in  follow- 
on  longer  term  programs  for  the  development  and  implementation  of  open  systems  for  enterprise 
integration.  It  is  anticipated  that  a  national  consensus  will  emerge,  resulting  in  a  United  States 
model  for  the  development  of  international  standard(s)  for  integrating  many  types  of  applications 
and  industries.  Opportunities  will  be  sought  for  cooperation  and  coordination  with  other  related 
international  efforts. 

This  task  for  development  of  a  preliminary  or  strawman  enterprise  integration  framework 
will  build  off  of  prior  and  ongoing  work  including  the  European  Strategic  Program  for  Research 
on  Information  Technology  (ESPRIT)  consortium  developing  a  Computer  Integrated 
Manufacturing  Open  Systems  Architecture  (CIM  OS  A).  For  a  number  of  reasons,  the  United 
States  has  been  slow  to  respond  in  a  unified,  coordinated  manner  to  this  activity.  To  facilitate  the 
design  of  a  comprehensive  enterprise  integration  framework,  the  approach  of  this  task  is  not  to 
start  from  scratch,  but  to  evaluate  the  relevance  of  leveraging  the  ESPRIT  CIM  OSA  effort  as  well 
as  other  potentially  relevant  existing  initiatives.  The  resulting  framework  will  provide  a  stable, 
low-risk  strategy  for  coordinated  investment  by  government  and  industry  in  automated 
infrastructures.  The  framework  will  also  provide  a  common  reference  model  for  establishing 
research  priorities,  modernization  of  DoD  activities,  and  standards  efforts.  A  number  of  closely 
coordinated  activities  of  the  sponsors  will  support  the  development  of  the  national  framework 
initiated  by  the  strawman  framework  from  this  effon. 

2.1.2  Scope  of  Effort 

This  enterprise  integration  strawman  framework  effon  shall  span  an  eight  month  time 
period.  There  will  be  two  tasks  executed  serially:  task  one  shall  last  two  months,  task  two  shall 
last  six  months.  The  objective  of  the  effon  is  to  employ  contractor  expertise  to  work  closely  with  a 
NIST-led  Framework  Advisory  Board  (FAB)  to  quickly  assess  the  state  of  the  art,  develop  a 
strawman  framework,  and  perform  a  domain  impact  study  for  the  framework.  While  the  focus  of 
the  effort  is  primarily  domain  independent,  the  contractor  shall  focus  primarily  (but  not 
exclusively)  on  aerospace  enterprise  issues  to  include  an  aerospace  organization's  interfaces  to  the 
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government  and  to  subtler  suppliers.  Task  1  should  not  exceed  25%  of  the  total  effort;  task  2  shall 
compose  the  remainder  of  the  effort. 

2.1.3  EIF  Tasks 

Task  1:  Preliminary  Scoping  Document  and  Development  Plan 

1.1  The  contractor  shall  submit  a  monthly  status  project  status  letter  to  the  AFPMO  to 
identify  significant  events,  accomplishments,  contractor/govemment  liason  activities/meetings, 
potential  problem  areas  or  issues,  and  related  progress  throughout  this  effon.  The  contractor  shall 
use  the  IDEF  methodologies  and  other  formal  structured  techniques  as  required  for  reporting 
results  when  appropriate.  The  contractor  shall  develop  and  document  a  management  plan  for 
performing  the  activities  of  task  1  and  task2. 

1.2  The  contractor  shall  develop  an  unclassified,  annotated  bibliography  and  assessment  of 
existing  material  which  is  relevant  to  the  framework  development.  Using  this  source  material,  the 
contractor  shall  extract  a  list  of  requirements,  issues,  measurement  criteria,  and  sources.  The 
contractor  shall  provide  input  to  the  NIST-led  FAB  in  order  to  develop  a  single  clear  mission 
statement  and  criteria  for  evaluating  the  success  of  the  framework  strawman. 

1.3  The  contractor  shall  develop  a  list  of  enterprise  processes,  building  a  matrix  showing 
how  each  process  contributes  to  mitigating  the  issues  in  achieving  enterprise  integration.  The 
contractor  shall  build  a  list  of  information  classes  for  each  process.  The  contractor  shall  develop  a 
glossary  of  enterprise  integration  terminology  to  submit  to  the  FAB  and  assist  in  the  development 
of  a  single,  consistent  glossary  to  be  finalized  by  the  FAB. 

1.4  The  contractor  shall  participate  as  authorized  by  the  AFPMO  in  government  led  and 
sponsored  discussions  with  national  and  international  organizations  such  as  ESPRIT. 

1.5  The  contractor  shall  evaluate  the  ESPRIT  CIM  OSA  work  and  any  other  relevant 
initiatives  identified  in  subtask  1.2,  and  make  recommendations  on  (a)  using  CIM  OSA  terms  and 
definitions  in  the  framework  and  in  the  enter-prise  integration  glossary,  (b)  extensions  to  CIM 
OSA  reference  architecture  needed  to  address  the  issues  identified  in  subtask  1.2,  and  (c)  using  the 
extended  CIM  OSA  reference  architecture  to  populate  the  framework  processes  in  task  2. 

1.6  Using  the  results  of  the  previous  subtask,  the  contractor  shall  develop  an  EIF 
development  plan  for  defining  a  strawman  framework  interms  of  requirements,  issues,  enterprise 
processes,  and  information  types  in  task  2. 

1.7  The  contractor  shall  present  the  results  of  task  1  and  the  EIF  development  plan  at  a 
government  sponsored  workshop.  Formal  approval  of  the  plan  shall  be  provided  by  the  AFPMO 
prior  to  the  execution  of  task  2. 

Task  2:  Development  of  a  Strawman  EEF 

2. 1  The  contractor  shall  develop  a  strawman  framework  for  enterprise  integration  based 
upon  open  systems  concepts  and  national  and  international  standards.  The  contractor  shall  update 
the  glossary  and  submit  it  to  the  AFPMO  to  be  finalized  by  the  FAB. 

2.2  The  contractor  shall  provide  a  report  analyzing  the  potential  impact  of  an  approved 
framework  on  current  programs.  Recommendations  on  the  methods  of  using  the  framework  in 
these  programs  and  anticipated  benefits  as  well  as  negative  impacts  shall  be  described.  The 
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example  matrix  of  subtask  1 .3  shall  be  employed,  showing  how  detailed  process  elements  in  these 
candidate  programs  map  to  the  strawman.  The  following  programs  shall  be  considered: 

Product  Data  Exchange  using  STEP  (PDES) 

DARPA  Initiative  in  Concurrent  Engineering  (DICE) 

Microelectronics  Manufacturing  Science  and  Technology  (MMST) 

Integrated  Composite  Center  (ICC) 

Integrated  Design  Support  (IDS) 

Advanced  Cost  Management  Systems  (ACMS) 

Automated  Airframe  Assembly  Program  (AAAP) 

any  other  suggested  program(s) 

2.3  The  contractor  shall  produce  and  deliver  a  final  Strawman  EIF  which  shall  be  prepared 
in  contractor  formats.  The  contractor  shall  present  the  strawman  framework  at  an  end  of  task 
briefing  to  the  AFPMO  and  their  cosponsors  and  selected  audiences  specified  by  the  FAB  and 
conveyed  in  writing  by  the  AFPMO.  The  contractor  shall  clearly  identify  all  open  issues  and 
alternatives.  The  contractor  shall  present  and  deliver  the  results  of  this  effort  to  the  AFPMO  via  the 
Prime  Contractor  for  continued  evaluation  and  use. 
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ENTERPRISE  INTEGRATION  FRAMEWORK  PROGRAM 
EXECUTIVE  SUMMARY 


EXEQmVE  SUMMARY 

The  current  Aerospace  and  Defense  environment  is  characterized  by  increasing  global  competi¬ 
tion,  funding  and  market  uncertainty,  rapidly  advancing  technology,  and  increasingly  demanding 
customers.  Today’s  enterprises  have  to  manage  greater  business  and  technology  risk,  respond 
more  quickly  to  changes  in  internal  and  external  conditions,  develop  closer  relationships  with  the 
customer,  leverage  corporate  resources  more  carefully,  and  provide  higher  quality  products  and 
services  at  a  reasonable  cost  and  with  a  reduced  span  time.  The  DoD  and  USAF,  after  much 
analysis,  have  determined  that  a  critical  success  factor  in  achieving  these  objectives  is  enterprise 
integration.  The  DoD  and  USAF,  on  the  basis  of  this  observation,  initiated  the  EIF  program  and  . 
took  a  major  step  in  the  development  of  a  comprehensive,  international  Enterprise  Integration 
Framework. 

The  integration  of  an  enterprise  is  a  multi-dimensional  exercise  in  which  people,  procedures,  in¬ 
formation,  equipment,  and  other  enterprise  elements  are  configured  so  that  they  have  parts  in 
common.  Enterprise  integration  is  manifested  in  many  ways  and  can  include  such  things  as: 

o  The  physical  integration  of  equipment  in  a  Flexible  Machining  System, 
o  The  integration  of  the  legal  infrastructure  in  a  trading  partnership, 
o  The  procedural  integration  of  several  requirements  analysis  approaches, 
o  The  logical  integration  of  information  systems. 

0  Human  integration  on  a  high  performance  work  team, 
o  Cultural  integration  in  a  strategic  partnership  (e.g.  GM  and  EDS). 

The  opportunities  for  enterprise  integration  are  numerous  and  have  to  be  understood  in  the  right 
context  to  be  prioritized  and  acted  upon.  The  most  meaningful  integration  context  is  that  of  the 
enterprise  processes.  Processes  normally  cross  the  functional  boundaries  of  today’s  organizations, 
integrating  the  flow  of  information  and  material  into  multi-functional  continuous  flow  processes. 
The  enterprise  processes  are  the  backbone  of  the  enterprise.  These  are  where  the  elements  of  an 
enterprise  come  together  in  the  creation  of  products  and  value  added  services.  Enterprises  are  in¬ 
tegrated  through  the  integration  of  their  processes.  Process  elements,  such  as  people,  informa¬ 
tion,  machines,  procedures,  methods,  or  objectives,  must  be  shared  in  order  to  bring  about  in¬ 
tegration.  The  Enterprise  Integration  Framework  has  to  support  process  (which  includes  technol¬ 
ogy)  integration  at  various  levels  of  detail  across  individual  organizations,  multi-organizational 
enterprises,  industries,  and  nations. 

Numerous  attempts  at  enterprise  integration  are  currently  underway  and  offer  insight  into  the  na¬ 
ture  of  integration.  The  Northrop/D.  Appleton/OCOMAR  and  IBM  EIF  teams  undertook  a  joint 
study  of  a  number  of  these  efforts  to  better  understand  their  relationship  to  the  objectives  of  the 
EIF  program.  The  study  led  to  a  better  understanding  of  the  individual  programs,  critical  success 
factors  for  integration,  and  the  many  types  of  frameworks  currently  being  developed.  The  effort 
also  established  a  program  comparison  format  for  the  positioning  of  the  various  initiatives.  By 
advancing  the  understanding  of  major  integration  programs,  the  first  step  is  taken  toward  the  in- 
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tegration  of  such  major  initiatives  as  DoD  CALS,  CIM-OSA,  SEMATECH,  PDES,  and  C-4.  The 
coordination  and  integration  of  these  programs  alone  would  be  a  major  political,  economic,  and 
technical  step  toward  the  accomplishment  of  enterprise  integration. 

The  body  of  knowledge  uncovered  during  our  program  analysis  comprises  many  important  les> 
sons.  Top  on  the  list  is  the  fact  that  the  enterprise  processes  must  be  understood  and  improved 
prior  to  their  automation  or  integration.  This  is  consistent  with  the  current  TQM,  Concurrent 
Engineering,  and  Continuous  Process  Improvement  initiatives  and  is  the  reason  for  process-based 
approach  proposed  for  the  EIF.  The  process  orientation  is  supported  by  the  use  of  models,  which 
are  a  common  element  in  all  successful  integration  efforts.  The  Northrop/D. 
Appleton/OCOMAR  EIF  has  been  developed  in  the  context  of  a  set  of  interrelated  enterprise 
models.  The  OCOMAR  aerospace  model  is  an  example  of  one  way  in  which  these  enterprise 
models  may  be  configured.  The  aerospace  model  also  addresses  another  important  element  of  en¬ 
terprise  integration,  the  integration  of  enterprise  requirements.  Enterprise  requirements  are  a  vi¬ 
tal  link  between  the  enterprise  management,  products,  services,  workers,  and  systems.  Enterprise 
requirements  and  objectives  must  be  well  understood,  analyzed,  flowed  down,  and  tracked.  The 
integration  of  this  process  is  central  to  the  improvement  of  the  enterprise. 

Successful  enterprise  integration  efforts  also  share  the  idea  of  a  control  architecture,  as  the  basis 
of  business  and  technical  integration.  A  control  architecture  is  especially  powerful  when  com¬ 
bined  with  the  use  of  business  performance  metrics.  The  performance  metrics  are  the  basis  for 
understanding  the  statistical  nature  of  the  business,  and  are  the  cornerstone  of  Business  Con¬ 
figuration  Management  (BCM).  BCM  is  the  key  to  the  management  of  a  dynamic  enterprise  in  a 
changing  environment.  BCM  allows  the  enterprise  to  be  understood  through  models  and  perfor¬ 
mance  metrics  and  continuously  improved  through  incremental  changes  in  the  business  process 
configuration.  The  EIF  supports  the  use  of  BCM  by  providing  an  architecture  for  the  integration 
of  the  business  processes. 

One  of  the  final  lessons  learned  from  other  integration  efforts  is  that  the  role  of  management  is 
critical  to  success.  This  fact  is  widely  known,  but  often  ignored.  The  Northrop/D. 
Appieton/OCOMAR  EIF  work  has  foctised  on  the  role  of  management  in  enterprise  integration. 
Areas  such  as  risk  management,  simulation,  requirements,  and  BCM  are  all  important  to  manage¬ 
ment.  A  management  oriented  simulation,  in  particular,  would  be  of  value  in  breaking  down  cul¬ 
tural  barriers  and  fostering  human  integration  within  the  enterprise.  The  value  of  the  framework 
is  seen  in  the  integration  of  these  areas  within  and  between  organizations. 

The  EIF  program  identifies  a  number  of  important  lessons  learned  and  provides  a  basis  for  un¬ 
derstanding  the  dimensions  of  enterprise  integration.  As  the  importance  of  enterprise  integration 
increases,  so  will  the  need  for  the  further  development  of  the  EIF. 
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BACKGROUND 


This  section  is  e  background  summarization  of  the  results  of  Phase  I  and  n  of  the  Enterprise  In¬ 
formation  Framework  (EIF)  study.  The  mission  of  the  Enterprise  Integration  Framework  (EIF) 
study  effort  is  to  define  and  develop,  for  national  consensus,  a  disciplined  top-down  approach  or 
framework  that  will  significantly  improve  U.S.  industrial  competitiveness  through  the  structural 
improvement  of  enterprise  and  trading  partner  processes,  to  support  farther  integration.  The 
purpose  of  Phase  I  was  to  define  the  scope  and  strategy  for  the  framework  development  to  be 
undertaken  in  Phase  n.  The  Problem  statement  of  this  final  report  describes  the  current 
American  industrial  environment,  the  impact  of  CIM  on  manufacturing  enterprises,  and  what 
changes  are  needed  in  the  future  to  increase  American  manufacturing  enterprise  productivity  and 
competitiveness.  The  Objectives  statement  summarizes  the  EIF  effort  in  terms  of  what  is  planned 
to  be  accomplished  and  how  these  plans  are  to  be  implemented.  The  Scope  section  describes  the 
expected  results  of  the  EIF;  and  finally,  the  approach  section  of  this  document  defines  the 
strategy  used  to  study  the  framework  concepts  and  develop  a  strawman  aerospace  model. 

We  decided  to  focus  our  EIF  efforts  in  a  single  industry  direction.  This  permited  the  developers 
to  describe  the  salient  features  of  manufacturing  operations  within  a  more  limited,  yet  fairly 
generalized  environment  that  can  thereafter  be  extended  to  other  manufacturing  industry  types. 
The  aerospace  and  defense  industry  was  chosen  for  this  focus  to  permit  the  developers  to  draw 
upon  their  extensive  knowledge  and  experience.  The  industry  oriented  EIF  reference  model  was 
used  to  critique  the  CIM-OSA  concepts. 

The  EIF  Strawman  Aerospace  Model  is  a  set  of  interrelated  reference  models  which  describe  the 
infrastructure  and  behavior  of  an  enterprise.  The  EIF  model  provides  a  conceptual  structure  to 
assist  management  in  determining  and  understanding  the  most  important  factors  that  are  influen¬ 
tial  to  the  overall  performance  of  the  enterprise.  This  EIF  model  is  different  from  more  tradi¬ 
tional  models  of  the  enterprise  in  that  it  deals  with  the  total  enterprise;  management  strategies, 
people,  facilities,  equipment,  computer  systems,  processes,  and  information;  within  the  context  of 
a  dynamic  high-technology  business  environment. 
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PROBLEM  STATEMENT 


State  of  the  American  Industry 

The  initial  part  of  our  study  dealing  with  the  developing  of  an  Enterprise  Integration  Framework 
(EIF)  was  a  review  of  current  literature  concerning  productivity  of  U^.  industry.  The  sources 
are  listed  in  our  Bibliography,  but  the  1989  MIT  Study  on  US.  Productivity  most  salieatly  helps 
us  to  define  the  first  issue.  The  findings  of  this  study  reveal  that  American  industry  has  not 
maintained  an  adequate  level  of  productivity  to  remain  competitive  with  the  Japanese  and 
European  industries. 

Because  of  past  efforts  America  has  become  the  leader  in  research  and  development;  however,  the 
advantages  of  this  position  will  fade  unless  significant  focus  is  placed  on  manufacturing  produc¬ 
tivity  in  terms  of  continually  improving  product  design  and  production  processes.  In  addition, 
American  industries  must  strive  to  develop  adequate  rewards  for  efforts  involved  in  making  these 
improvements.  The  report  further  states  that  in  order  to  attain  effective  productivity,  American 
companies  must  place  stronger  emphasis  on  improved  quality,  lowering  cost,  and  innovation  as 
measures  of  performance  in  relation  to  the  strongest  competitor. 

The  Report's  single  most  useful  recommendation  is  that  American  companies  should  measure 
their  performance  -  in  raising  quality,  lowering  cost,  and  innovating  -  against  the  best  companies 
wherever  they  are.  '^e  have  consistently  tended  to  underestimate  the  competition”,  says  Sloan 
School  Dean  Lester  Thurow. 

The  most  sweeping  conclusion,  and  perhaps  the  most  striking  one,  takes  the  commission  far  from 
its  early  focus  on  productivity  to  urge  more  cooperation  in  all  aspects  of  business  -  within  com¬ 
panies,  between  companies  and  their  suppliers  and  customers,  and  among  companies  in  the  same 
industry.  Furthermore,  the  study  identified  patterns  common  to  firms  that  are  adapting  success¬ 
fully  to  the  continual  global  change  in  business.  These  include  many  of  the  concepts  that  make 
up  TQM  initiatives  launched  by  the  Defense  Department  and  aerospace/defense  contractors,  such 
as: 


o  Developing  closer  ties  to  customers  and  meeting  their  needs, 

o  A  focus  on  continuous  improvement  of  processes  to  reduce  cost  and 

improve  quality  of  products  or  services. 

o  Fostering  closer  quality-based  relationships  with  a  select  group  of  suppliers, 
o  Breaking  down  organizational  hierarchies  to  improve  communication 

between  traditional  functional  areas.  Levels  of  management  are  reduced 
and  fewer  separate  units  are  the  end  result, 
o  Applying  technology  to  advantage  through  a  strategic,  long-term  approach, 
o  Developing  human  resource  policies  and  rewards  that  promote  employee 
participation,  teamwork,  flexibility  and  continuous  learning. 

A  key  point  is  made  by  one  of  the  primary  authors  of  the  report,  Michael  L.  Dertoouzos.  He 
states  that  these  concepts  must  be  implemented  as  a  unified  strategy,  not  a  pick-list  of  individual 
items  for  implementation. 
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Computer  Integrated  Manufacturing  (CIM) 

The  second  issue  is  most  effectively  covered  in  the  Computer  Integrated  Manufacturing  (CIM) 
Report  for  the  House  Armed  Services  Committee  by  the  Office  of  the  Secretary  of  Defense,  1989. 
This  report  addresses  the  technical  feasibility,  cost  and  benefits  of  world  class  manufacturing, 
and  analysis  and  planning  techniques  of  CIM  implementation. 

This  discussion  addresses  CIM  feasibility  as  a  whole,  not  just  as  it  relates  to  defense  production. 
Most  of  the  challenges  encountered  by  commercial  industry  are  also  encountered  by  defense  in¬ 
dustries.  The  implementation  of  CIM  does  not  necessarily  require  that  existing  equipment,  sys¬ 
tems,  and  procedures  be  replaced.  Integration  is  basically  an  organizational  issue,  with  technical 
changes  following  organizational  changes.  However,  a  proper  foundation  must  be  established  for 
CIM  to  succeed.  First,  cultural  and  organizational  changes  must  be  made  to  obtain  a  simplified 
organization  and  to  promote  clear  lines  of  communication.  There  must  be  changes  in 
management’s  outlook  on  long  term  investments  and  the  return  on  these  investments.  After  an 
integrated  manufacturing  environment  is  established  and  the  manufacturing  processes  are  under¬ 
stood,  it  is  appropriate  to  turn  to  an  analysis  of  computer  applications  to  aid  in  manufacturing. 
The  underlying  requirements  for  implementing  CIM  are  management  commitment  and  active 
participation,  a  top  down  implementation  strategy,  and  education  of  managers  and  users.  The 
basic  message  is  that  technical  tools  are  available  to  implement  CIM  and,  software  tools  for 
managing  and  integrating  an  enterprise  are  also  available,  as  well  as  systems  to  Laudle  large 
amounts  of  data,  including  relational  data  bases;  however,  before  these  can  be  effectively 
deployed,  the  management  infrastructure  (of  policies,  motivation,  organization,  etc.)  must  be  sig- 
niHcantly  improved. 

The  report  found  that  investments  in  CIM  are  generally  recouped  within  five  years,  if  properly 
instituted.  These  findings  were  based  on  several  case  studies  which  concluded  that  80%  of  the 
savings  resulted  from  cultural  and  organizational  changes.  These  changes  required  very  little 
capital  investments.  Moreover,  the  expense  of  CIM  implementation  can  vary  dramatically 
depending  on  the  amount  of  currently  existing  technology  and  on  the  particular  manufacturing 
processes  being  supported. 

The  Secretary  of  Defense’s  office  defined  World  Class  Manufacturers  as  those  companies  that 
area  able  to  compete  based  on  high  quality  and  low  cost  in  the  world  market;  and,  Richard 
Schonberger  adds  to  this  definition  those  companies  that  have  implemented  CIM.  Therefore,  the 
external  influence  of  competitive  pressures  have  made  CIM  implementation  more  pressing.  From 
the  position  of  the  world  class  market,  CIM  means  managing  a  manufacturing  company  through 
the  use  of  technology.  The  management  of  the  company  therefore  necessitates  organizational 
restructuring  around  team  work,  concurrent  engineering  and  new  or  better  accounting  methods. 

The  final  area  of  the  study  addressed  is  analysis  and  planning  techniques  for  use  in  implementing 
CIM.  The  planning  for  CIM  involves  the  definition  of  processes,  products,  and  information  re¬ 
quired  to  support  the  business.  Requirements  for  change  are  then  based  on  integrating  processes 
and  information  flows  to  improve  the  operations.  One  of  the  methodologies  developed  in  support 
of  this  process  is  IDEF  (ICAM  Definition)  which  defines  the  relationships  between  functions  and 
information  to  produce  products.  In  addition,  the  study  concludes  that  additional 
tools/methodologies  are  required  to  support  the  analysis  of  costs  (direct  and  indirect)  and 
material;  also  the  analysis  of  hardware  and  software  in  order  to  optimize  the  CIM  implementa¬ 
tion. 
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Future  Menagement  Responsibilities 

The  third  and  last  part  of  our  issue  definition  is  identified  in  an  article  TT  (Information  Tech¬ 
nology)  in  the  1990s:  Managing  Organizational  Interdependence,”  Sloan  M^gement  Review, 
Winter,  1989.  This  article  concurs  with  the  other  two  in  that,  American  companies  must  make 
considerable  changes  in  order  to  compete  with  Japanese  and  European  industry.  Some  of  the 
«  changes  in  culture  and  organizational  structure  will  require  substantial  reorientation  in  manage¬ 
ment  as  well.  Management's  role  wiU  become  increasingly  more  complex  because  of  organization 
changes  which  impact  the  internal  processes  and  proc^ures  of  how  work  is  currently  ac¬ 
complished.  In  addition,  management's  participation  will  be  more  challenging  because  of  teaming 
efforts  which  result  in  unclear  lines  of  authority  and  decision  making.  With  regard  to  the  team¬ 
ing  efforts,  managen  will  need  improved  skills  in  task-definition  and  dealing  with  "subordinates” 
as  peers.  Ako,  with  the  onset  of  changes  in  American  industry,  management  will  need  to  develop 
new  methods  for  measuring  performance/success  of  individuak  who  participate  in  these  teams  as 
well  as  the  team  itself. 

The  future  role  of  management  must  include  new  planning  approaches  fostered  by  more  effective 
use  of  information  and  simulation  tools  which  emphasize  relevant  and  critical  issues.  Finally,  the 
development  of  an  information  technology  infrastructure  based  on  networked  data  will  facilitate 
a  foundation  for  productive  integration.  The  article  further  states  that  the  challenge  here  is  for 
management  to  understand  the  future  effect  of  current  investments  in  organization  and  technol¬ 
ogy  to  aid  the  people-intensive,  integration  mechanisms  resulting  from  competitive  pressures. 


Summary 

To  become  world  class,  UJS.  industrial  companies  must  rethink  some  basic  management  premises, 

including: 

(1)  Performance  must  be  measured  against  the  bpst  of  the  competition. 

(2)  The  basic  processes  used  in  our  businesses  must  be  restructured  for  better  flow  of  infor¬ 
mation  and  product,  .and  then  must  be  continuously  measured  in  terms  of  performance 
and  continuously  improved,  ala  TQM  principles. 

(3)  Automation  is  available  and  can  increase  productivity,  but  primary  attention  should  be 
focused  on  improving  the  management  infrastructure,  including  policies,  processes,  and 
organization. 


What  Is  Needed  Now? 

American  industries  should  embark  upon  a  multifaceted  effort  aimed  at  improving  both  the 
management  and  technical  processes  of  product  development  This  may  require  a  wide-spread 
industry  education  program.  In  the  case  of  the  aerospace  industry,  the  Department  of  Defense 
should  take  the  leadership  role  in  viewing  the  industrial  processes  top-down,  and  overcome  the 
organizational  barriers  that  prevent  aerospace  managers  from  seizing  this  initiative  primarily  by 
adjusting  its  acquisition  policies  to  better  reflect  the  team  management  premises  of  the  previous 
paragraph.  The  aerospace  industry  must  develop  improved  processes  to  manage  the  enterprise  in 
ways  that  are  most  beneficial  to  producing  the  final  deliverable,  which  is  what  the  Department  of 
Defense  is  most  interested  in  as  the  eventual  customer.  Industry  has  generally  been  unwilling  or 
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unable  to  take  this  action  in  any  unified  fashion^  for  a  variety  of  reasons.  However,  once  this  in¬ 
itiative  is  properly  developed  and  understood,  the  Department  of  Defense  can  promote  it  through 
its  acquisition  policies. 

To  do  this,  the  Department  of  Defense  needs  an  unbiased,  top-down  management  vision  of  the 
industrial  environment.  This  means  that  the  industrial  processes  must  be  portrayed  according  to  a 
set  of  established  rules  that  do  not  reflect  any  one  company’s  view  of  functional  or  departmental 
constraints.  The  Enterprise  Integration  Framework  is  such  a  vision.  It  depicts  the  enterprise  in 
terms  of  (1)  the  integrated  processes  that  really  are  taking  place  (but  currently  in  highly  ineffi¬ 
cient  means)  and  which  must  be  more  effectively  structured  and  managed;  (2)  the  information 
reqxurements  of  processes  (rather  than  of  organizations);  and.  (3)  the  tools  and  technologies 
needed  to  make  the  enterprise  function  besL 

By  using  the  EBF  the  Department  of  Defense  can  promote  the  development  of  industry  accepted 
process  'templates*  around  which  commercial  vendors  can  rally  to  develop  process  tools  (in  much 
the  same  way  as  PDES  and  EDI  ve  developing  standards  for  information  technology  integration). 
Vendors  and  industry  leaders  will  also  use  the  framework  to  guide  development  of  management 
processes  that  when  taken  together  will  yield  vastly  improved  industrial  operations  and  ultimately 
world-wide  competitiveness. 

The  framework  must  address  three  distinct,  but  not  unrelated,  business  environments  and  these 
are  illustrated  in  Figure  2-1.  At  the  root  of  this  context  is  the  single  business  enterprise,  com¬ 
posed  of  distinct  functional  organizations  that  work  to  achieve  enterprise  results. 

The  other  two  areas  of  interest,  trading  partners  and  industry,  involve  interorganizational 
cooperation  of  independent  enterprises.  The  first  of  the  interorganizational  or  multi-enterprise 
efforts  involves  integration  of  the  efforts  among  non-competing  business  enterprises  in  the  so- 
called  trading  partners  environment.  The  multiple  enterprises  join  together  to  cooperatively 
produce  a  final  product.  Alternatively,  there  are  multi-enterprise  efforts  involving  non- 
cooperative,  highly  competitive  business  enterprises.  These  enterprises  operate  within  the  bounds 
of  what  we  customarily  call  an  industry.  Foreign  interests  have  achieved  significant  industry  im¬ 
provement  through  cooperative  efforts  of  independent  enterprises.  The  development  of 
industry-wide  standards  that  permit  national  productivity  gains  in  combating  foreign  competition 
is  viewed  as  a  principal  means  of  addressing  this  competitive  issue. 

Regardless  of  the  breadth  and  depth  of  the  solutions  developed,  the  framework  must  address  all 
three  areas  of  integration  concerns  in  order  to  be  of  ultimate  value  in  improving  the  enterprise, 
product  development,  and  industry-wide  optimization  and  effectiveness  in  the  national  and  in¬ 
ternational  marketplace. 
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OBJECTIVE 


The  objective  of  the  Enterprise  Integration  Framework  (EIF)  task  has  been  to  define  and 
develop,  for  national  consensus,  a  discii  used  top-down  "context”,  or  strawman  framework  that 
will  significantly  improve  U^.  industrial  competitiveness  through  enterprise  and  trading  partner 
integration. 


SCOPE 

The  scope  of  the  EIF  program  has  been  to  develop  a  decision  tool  which  middle  and  executive 
levels  of  customer  agencies,  contractors,  and  information  technology  developen  may  use  as: 

o  A  refined  focus  for  current  and  emerging  government  and  industry 
improvement  initiatives. 

o  A  comprehensive  structure  for  establishing  trading  partner 
working  relationships  -  resulting  in  the  idcntj  'icaticn  >  - 
requirements  for  management  standards  to  facilituic  ir.  ..  - 
company  processes  and  information  sharing. 

o  A  guide  for  planning  and  implementation  of  improved  management 
strategies  and  processes  within  individual  manufacturing  enterprises. 

0  A  structured  and  systematic  overview  of  enterprise  integration 
concepts  and  requirements  for  system  builders  and  integrators. 

o  An  overall  requirements  context  for  development  and  demonstration 
of  enabling  technologies  through  both  cooperative  and  private 
development  projects. 

0  A  unifying  concept  for  common  industry  standards  for  enabling 
technologies  -  resulting  in  improved  technology  vendor  support 
for  manufacturing  enterprises. 
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APPROACH 


The  work  in  Phase  I  of  the  EIF  project  was  oriented  at  establishing  foundation  concepts  and  an 
overall  approach  from  which  a  comprehensive  EIF  strawman  could  be  developed.  Based  on  this 
preliminary  work.  Phase  II  solidified  the  Phase  I  findings  and  demonstrated  the  validity  and  ap¬ 
propriateness  of  the  framework  concepts.  Therefore,  in  order  to  ensure  that  the  EIF  would  be 
developed  with  the  appropriate  perspective,  varied  sources  of  information  were  sought.  Avail¬ 
able  information  that  related  to  architectural  frameworks,  CIM,  and  the  American  industrial  en¬ 
vironment  was  evaluated.  Throughout  this  effort  a  cross  section  of  publications  and  reference 
documents  were  used  to  establish  the  formulation  of  the  EIF  concepts.  As  part  of  the  research  a 
bibliography  was  created  which  documents  the  source  of  references  which  were  utilized  for  this 
project.  The  material  contained  in  the  bibliography  (see  Section  Five)  relates  to  various  topics, 
some  of  which  are  available  to  the  general  public  and  others  which  are  specific  to  particular  en¬ 
terprises.  Nevertheless,  they  all  contributed  to  an  understanding  and  the  development  of  EIF 
concepts. 

One  of  the  more  valuable  of  these  references  was  the  work  of  the  European  consortium  of  com¬ 
panies  working  on  a  similar  concept  for  an  Open  System  Architecture  for  Computer  Integrated 
Manufacturing  (CIM-OSA)  in  Europe.  Initial  evaluations  of  their  CIM-OSA  Reference  Architec¬ 
ture  Specification  and  Tutorial  has  revealed  some  potentially  valuable  concepts  that  are  being 
developed  to  support  business  process  definition  and  the  integration  of  enabling  technology. 
However,  additional  definition  is  required  before  the  concepts  can  be  proven  or  validated. 

As  the  reference  material  was  identified  and  analyzed,  the  team  conceptualized  and  continually 
refined  an  aerospace  strawman  concept  for  a  generalized  framework  that  can  be  used  by  much  of 
the  United  States  aerospace  manufacturing  industry  to  guide  operational  and  management  changes 
that  result  in  manufacturing  productivity  and  product  quality  improvements.  The  experience  of 
the  team,  when  combined  with  the  material  extracted  from  the  references,  was  used  to  define  an 
appropriate  bound  for  the  framework,  as  well  as  the  contents  of  each  of  the  views  or  elements 
contained  therein. 


The  views  or  elements  of  the  aerospace  strawman  model  were  studied  and  defined  in  greater 
levels  of  detail,  although  not  all  were  analyzed  to  the  same  degree  within  the  bounds  of  this  con¬ 
tract.  Due  to  contract  resource  limitations,  the  efforts  here  concentrated  on  those  elements  that 
are  expected  to  bear  the  greatest  relevance  to  integration  of  enterprise  and  multi-enterprise 
operations.  These  include: 


0  the  management  and  operational  issues  that  drive  the  need  for  change, 
o  structured  improvements  to  the  processes  that  are  performed  in  enterprises, 

o  the  shared  information  classes  that  comprise  the  information  flow  needed 

to  sustain  the  processes,  and 

o  the  evaluation  metrics  that  are  used  to  measure  the  process  effectiveness 
and  changes  introduced  into  them. 

The  aerospace  model  consists  of  the  necessary  general  rules  that  properly  interrelate  the  elements 
of  that  model.  In  other  words,  the  team  developed  the  relationships  between  the  issues, 
processes,  etc.,  such  that  exercising  of  the  results  provides  a  reasonably  accurate  representation  of 
an  aerospace  enterprise’s  operations.  For  the  aerospace  model,  these  interrelationships  are  called 
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element  extensions,  and  the  sum  of  all  the  extensions  is  the  aerospace  model.  Combined  with  a 
methodology  for  employing  the  model,  the  EIF  aerospace  model  is  conceptualized.  This  result  is 
presented  in  Section  Four,  EIF  Aerospace  Simulation  Model. 

Aerospace  industry  consensus  needs  to  be  sought  for  the  extensions  that  define  the  industry 
model.  Again,  the  reference  material  and  EIFWG  (Enterprise  Integration  Framework  Working 
Group)  participation  should  be  the  prime  validation  mechanisms.  On  the  other  hand,  'prototype” 
testing  and  validation  of  the  strawman  framework  was  accomplished  by  using  the  framework  to 
compare  a  select  number  of  government  sponsored  projects  and  initiatives.  Such  initiatives  as 
CALS  n  (Computer-Aided  Acquisition  and  Logistics  Support),  PDES  (Product  Definition  Ex¬ 
change  Standard),  and  AAAP  (Automated  Airframe  Assembly  Program)  are  included  in  Section 
Three  of  this  study. 


TASK  GROUPING^; 

A  series  of  tasks  were  designed  to  develop  at  a  conceptual  level  what  a  functional  model  repre¬ 
sents  and  to  study  the  viability  of  utilizing  the  CIM-OSA  Framework  as  a  candidate  for  the  En¬ 
terprise  Integration  Framework.  In  addition,  for  educational  purposes,  several  special  studies 
were  requested  from  the  EIF  Working  Group. 

Phase  I  of  the  EIF  Program  was  devoted  to  conceptualizing  a  functional  (aerospace)  model  and 
studying  framework  requirements. 

Phase  II  continued  on  with  the  development  of  the  functional  (aerospace)  model,  evaluation  of 
the  CIM-OSA  Framework,  and  several  educational  tasks  for  the  EIFWG. 

The  task  assignments  by  this  grouping  is  as  follows; 


A. 


Framework  Studies 

2.1  Lessons  Learned 


2.2  IDEF-0  &  IDEF-IX  Analysis  with  CIM-OSA 

2.4  Evaluation  of  Enterprise  Integration  Framework 

2.6  EIF  National  Initiative  Program  Positioning 

2.8  ESPIRIT  QM-OSA  Assessment 

2.9  Mapping  of  the  EIF  Aerospace  Strawman  Model 
Onto  the  CIM-OSA  Framework 


B.  Functional  (Aerospace!  Model 

2.5  Development  of  EIF  Aerospace  Strawman  Model 

2.10  Conceptual  Definition  of  EIF  Aerospace  Simulation  Model 

C.  EIFWG  Educational  Studies 

2.3  Jigsaw  Puzzle  Mapping 

2.7  AFX  Cost  Reduction  Scenario 
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The  following  section  summarizes  each  of  these  tasks. 


TASK 


2.1  Lessons  Learned  ■>  Actlrlty  Modeling 

This  study  was  requested  in  order  to  document  Northrop  Aircraft  Division's  experience  in 
using  IDEF-0  activity  modeling.  NAD  has  been  using  this  methodology  since  our  initial  involve¬ 
ment  in  early  ICAM  work.  The  summary  and  conclusions  contained  in  this  report  were  as  fol¬ 
lows: 


Northrop  now  has  a  number  of  years  experience  in  using  the  IDEF-0  methodology  to 
develop  activity  models.  This  experience  has  taught  us  some  valuable  lessons  concerning  the 
IDEF-0  methodology,  how  that  methodology  can  be  strengthened,  how  the  use  of  such  models 
can  be  extended,  and,  in  particular,  some  extensions  to  the  methodology  which  would  be  useful 
for  process  modeling. 

The  Europeans  (CIM-OSA)  are  currently  developing  new  standards  for  process  modeling. 
It  is  important  that  the  United  States  moves  to  protect  the  very  large  and  valuable  legacy  we  have 
in  IDEF  models  by  developing  extensions  and  improvements  for  the  current  IDEF-0  constructs, 
so  that  the  mass  of  existing  IDEF  models  may  be  converted  and  used  in  the  future.  We  should 
try  to  do  this  cooperatively  with  CIM-OSA,  if  at  all  possible,  as  both  the  Europeans  and  the 
United  States  will  benefit  from  this  cooperation. 

These  extensions  should  tie  activity  models,  and  the  information  about  how  a  company 
does  business,  directly  to  the  information  architectures,  control  architectures,  and  system  ar¬ 
chitectures  which  that  company  uses  to  manage  and  direct  technology  development  and  im¬ 
plementation. 

These  extensions  should  also  lead  to  the  ability  to  computer  simulate  IDEF-0  models. 
Computer  simulatable  process  models  should  become  as  important  as  a  tool  to  the  management  of 
U.S.  industry  as  structural  models  are  to  the  aerospace  structural  engineer.  An  integrated  CASE 
tool  should  be  developed  to  support  the  development,  validation,  and  use  of  these  models.  If  we 
succeed  at  this,  we  will  have  converted  the  IDEF  methodology  from  a  suspect,  labor-intensive 
*toy”  of  too  little  recognizable  benefit  to  management,  to  a  fundamental  management  tool  used  to 
continuously  develop  and  refine  processes  to  meet  increasingly  competitive  business  standards. 


2.2  IDEF-0  A  IDEF-IX  ANALYSIS  WITH  CIM-OSA 

This  study  was  requested  in  order  to  define  the  relationships  between  the  IDEF  modeling 
techniques  and  those  under  development  by  CIM-OSA.  The  results  of  this  study  are  summarized 
as  follows: 

'CIM-OSA  modeling  efforts  apparently  have  concentrated  on  developing  highly  refined  process 
modeling  techniques.  These  techniques  provide  for  certain  formalities  in  definition  of  processes 
that  are  not  inherent  in  the  IDEF-0  activity  modeling  methodology.  The  techniques  described 
rely  heavily  on  a  ’forms’  type  of  documentation.  It  does  not  appear  that  there  is  a  well  defined 
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graphic  syntax  for  specifying  the  interactions  among  processes  and  activities.  It  abo  seems  that 
there  are  some  differences  between  the  CIM-OSA  and  IDEF-0  philosophies  for  the  application  of 
process  and  activity  modeling  to  the  enterprise. 

Information  modeling  techniques  developed  for  CIM-OSA  are  less  advanced  and  refined  than 
their  process  modeling  techniques.  CIM-OSA  has  identified  the  need  to  use  a  three-schema  ap¬ 
proach.  There  is  a  Meta-Model  relating  the  three  schemata.  The  Meta-Model  incorporates  con¬ 
siderable  detail  about  the  external  information  views  as  objects  and  relationships  among  objects. 
On  the  other  hand,  there  is  minimal  detail  about  the  Conceptual  Schema  and  Internal  Schema. 

There  is  no  indication  that  there  are  manuals  or  training  materials  for  the  modeling  methods 
similar  to  those  for  IDEF-0  and  IDEF-IX. 


Task  2.3  "Jigsaw  Puzzle”  Mapping 

This  study  was  requested  by  the  EIF  Working  Group.  It  consisted  of  a  comparison  of  En¬ 
terprise  Integration  Framework  Characteristics  versus  those  of  other  known  integration  programs. 
The  results  of  this  study  were  incorporated  into  the  EIF  National  Initiative  Program  Positioning 
Report,  Section  Three. 


Task  2.4  Evaluation  of  Enterprise  Integration  Frameworks 
and 

Task  2.8  ESPIRIT  CIM-OSA  Assessment 

These  studies  were  requested  to  define  areas  a  framework  must  encompass.  The  results  of 
these  studies  are  summarized  as  follows: 


EIF  Concepts 


EIF  Program  Comparison 

Enterprise  integration  has  been  the  subject  of  a  wide  variety  of  development  activities.  A 
study  of  these  activities  was  undertaken  by  the  Northrop/D.  Appleton  Co./OCOMAR  and  IBM 
EIF  teams.  The  result  was  a  better  understanding  of  the  individual  programs,  critical  success  fac¬ 
tors  for  integration,  and  the  many  types  of  frameworks  currently  under  development.  A  baseline 
comparison  format  was  also  created  for  the  positioning  of  the  various  initiatives. 

A  complete  list  and  profile  of  all  programs  studied  is  contained  in  the  EIF  National  In¬ 
itiative  Program  Positioning  document  (Section  Three).  The  programs  were  analyzed  and  com¬ 
pared  from  a  variety  of  perspectives  including  problem  definition,  scope  of  integration,  integra¬ 
tion  solution  strategies,  modeling  techniques,  and  type  of  deliverables.  This  work  is,  potentially, 
a  first  step  in  the  integration  of  such  major  programs  as  DoD  CALS,  PDES,  SEMATECH, 
CIM-OSa,  and  C-4.  Full  scale  coordination,  cooperation,  and  integration  of  these  programs 
alone  would  represent  a  major  political,  technical  and  economic  step  toward  the  objective  of  en¬ 
terprise  integration. 
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Types  of  Frameworks 

During  the  course  of  the  EIF  program,  it  was  concluded  that  there  are  a  number  of  dif¬ 
ferent  types  of  frameworks  that  support  different  levels  and  types  of  enterprise  integration.  Each 
level  of  framework  forms  a  rough  umbrella  over  the  next  lower  level.  Higher  level  frameworks 
exhibit  a  greater  scope,  while  lower  levels  contain  a  greater  amount  of  detail. 

The  principal  frameworks  that  were  identified  (in  ascending  order)  are  the  following: 

Technology^oriented  Frameworks  view  the  enterprise  as  a  customer  for  information  tech¬ 
nology  products.  A  technology  framework  defines  components  and  standard  interfaces 
for  various  pieces  of  information  technology.  Major  vendors,  such  as  IBM  and  DEC, 
have  their  own  frameworks  which  define  how  their  products  work  together.  As  the 
demand  for  open  systems  has  increased,  greater  emphasis  is  being  placed  on  standards, 
defined  as  a  cooperative  effort  between  vendors  and  users  to  permit  the  interoperability 
of  multiple  vendors  products  and  to  allow  for  smooth  transitions  to  new  technology. 
Many  of  today’s  standards,  such  as  SQL,  focus  on  interfaces  to  information  technology 
products,  totally  independent  of  the  business  integration  strategy. 

Firm^oriented  Frameworks  see  the  enterprise  as  a  single,  vertically  integrated  business 
unit  and  view  the  integration  objective  as  improving  throughput  of  products  and  increas¬ 
ing  productivity.  In  the  past,  many  firm-oriented  frameworks  were  actually  only  slight 
variations  of  one  or  two  vendors’  technology  frameworks.  An  MRP  software  package,  for 
example,  was  identified  as  a  component  of  integration  through  the  process  of  inventory 
management  remained  undefined.  However,  the  insight  that  process  simplification  must 
precede  automation  has  led  many  firms  to  focus  on  the  business  process  architectures, 
which  stand  apart  from  a  specific  architecture  for  hardware  and  software,  but  can  map  to 
it.  Many  manufacturing  companies  have  formalized  their  own  internal  architectures  for 
integration  and  in  some  cases  have  placed  individuals  in  charge  of  maintaining  the  ar¬ 
chitecture.  A  top-down  factory  analysis  study  conducted  as  part  of  a  Phase  1 IMIP  con¬ 
tract  is  an  example  of  this  type  of  framework. 

Conglomerate-oriented  Frameworks  view  the  enterprise  as  a  collection  of  semi¬ 
independent  business  units  that  operate  under  the  same  corporate  umbrella.  Many  con¬ 
glomerates  have  from  10  to  100  strategic  business  units  (SBUs)  and  strategic  support  unts 
(SSUs).  These  SBUs  and  SSUs  operate  autonomously  and  interdependently,  according  to 
the  roles  assigned  to  them  by  a  higher  level  corporate  authority.  In  this  environment,  the 
framework  describes  general  operational,  financial,  and  technaical  standards  for  control¬ 
ling  these  diverse  elements  of  the  corporate  resource  portfolio.  These  standards  usually 
relate  to  "common  business  processes'  and  'common  information  technology”.  Although 
each  SBU  may  have  its  own  firm -oriented  integration  framework,  the  conglomerate 
framework  must  define  how  SSUs  interact  with  SBUs.  The  NADSARP  architecture  is  an 
example  of  a  conglomerate  framework. 

Trading  Partner-oriented  Frameworks  view  the  enterprise  as  a  team  of  firms  that  work 
together  to  produce  products  and  services  for  a  specific  group  of  customers.  Various 
elements  of  each  firm  become  a  value  chain.  The  framework  improves  interorganizational 
efficiency  by  integrating  the  business  processes  and  information  technologies  of  team 
members.  In  the  past,  the  default  strategy  has  been  to  adopt  the  conglomerate  framework 
of  the  prime  contractor  as  the  framework  of  the  team.  As  team  relationships  have  grown 
more  dynamic,  this  approach  has  become  unacceptable.  The  problem  is  especially  sig¬ 
nificant  at  the  subcontractor  level  where  a  single  subcontractor  may  have  to  support  a 
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number  of  conflicting  prime  contractor  standards.  Trading  partner-oriented  frameworlcs 
mxist  therefore  rely  heavily  upon  standards  which  all  team  members  can  support.  The 
GM  C4  Program  is  an  example  of  an  integration  effort  which  is  primarily  a  trading 
partner  framework. 

Industry-oriented  Frameworks  view  the  enterprise  across  a  group  of  firms  with  a  common 
product  and  customer  focus.  These  frameworks  establish  common  standards  for  business 
processes  and  deployment  of  information  technology  which  will  aid  the  formation  of  trad¬ 
ing  partner  teams.  Industry  frameworks  are  becoming  more  and  more  important  to 
resolve  conflicting  standards  of  conglomerate  and  trading  partner  team  frameworks.  They 
also  have  an  interesting  side  effect  in  that  they  establish  market  requirements  for  infor¬ 
mation  technology  products.  The  CALS  Program  is  a  good  example  of  an  industry 
framework  where  ^e  DoD  is  a  common  customer  served  by  many  different  trading 
partner  teams. 

Clobal-oriented  Frameworks  view  the  enterprise  as  existing  across  international  bound¬ 
aries.  Such  frameworks  seek  to  create  international  standards  that  foster  multi-national 
industries.  As  with  the  preceding  frameworks,  the  global  combines  the  traits  of  various 
frameworks  to  achieve  a  more  extensive  form  of  enterprise.  Thus  global  frameworks  in¬ 
corporate  the  characteristics  needed  to  address  industry,  trading  partner,  conglomerate, 
and  firm  issues.  The  current  effort  to  unify  the  U.S.  and  European  aspects  of 
SEMATECH  is  an  example  of  an  international  effort.  In  addition,  there  is  interest  in  ex¬ 
tending  CALS  to  an  international  base,  and  also  in  elevating  its  concepts  to  address  mul¬ 
tiple  industry  issues. 

These  six  types  of  frameworks,  in  fact,  represent  six  types  and  views  of  enterprises.  Each  one 
serves  a  purpose  and  addresses  a  different  dimension  of  integration.  The  frameworks  reflect  the 
evolution  of  integration  approaches  and  the  different  views  of  integration  found  at  the  various 
levels  of  an  enterprise.  Integration  frameworks  initially  arose  out  of  a  need  to  integrate  informa¬ 
tion  systems.  In  time  the  growing  awareness  of  non-technical  integration  issues  resulted  in  in¬ 
creasingly  process -oriented  frameworks  with  an  expanding  scope  of  application.  Each  level  of 
framework  seeks  to  guide  the  application  of  lower  level  frameworks  so  that  information  systems, 
firms,  conglomerates,  trading  partners,  industries  and  nations  can  be  better  integrated.  It  is  pos¬ 
sible  for  several  of  the  frameworks  to  exist  at  the  same  time  and  even  within  the  same  enterprise. 
Technology  frameworks,  for  example,  are  a  component  of  many  higher  level  enterprise 
frameworlu.  The  specific  relationships  among  a  set  of  frameworks  is  dependent  upon  the 
specific  objectives  of  the  enterprise.  In  one  case  the  objective  may  be  information  systems  in¬ 
tegration  and  in  another,  the  objective  may  be  physical  integration  of  machine  tools,  or  the  in¬ 
tegration  of  a  strategic  planning  team.  These  different  objectives  influence  the  types  of 
frameworks  required  and  the  relationships  among  them. 


Three  Architectures 

Every  program  reviewed,  regardless  of  the  framework  type  involved,  identified  the  in¬ 
tegration  and  sharing  of  information  across  all  businesses  processes  throughout  the  product  life 
cycle  as  a  principal  strategy  for  integration.  A  common  reference  point  for  these  strategies  was  a 
concept  developed  by  the  American  National  Standards  Institute  in  1971  called  the  "three -schema 
architecture*.  This  idea  is  supported  by  ISO  work  and  is  fundamental  to  CIM-OSA  as  well  as 
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many  of  the  Air  Force  ICAM  projects.  The  IBM  repository,  central  to  IBM’s  integration 
strategy,  also  utilizes  it.  Basically,  the  three-schema  architecture  separates  data  management  into 
three  related  but  distinct  views: 

o  External  Schemas,  which  define  information  as  it  supports  the  requirements  of  en¬ 
terprise  activities. 

o  Internal  Schemas,  which  define  the  structures  that  store  information  in  an 
automated  environment. 

o  A  single  Conceptual  Schema,  which  establishes  one  set  of  consistent  data  defini¬ 
tions  and  integrity  rules  used  to  logically  integrate  and  consistently  interpret  the 
enterprise  data. 

Although  the  three-schema  approach  was  developed  specifically  to  improve  data 
management,  early  ICAM  projects  extended  it  to  delineate  three  types  of  architectures  for  ad¬ 
dressing  overall  integration  problems.  This  three  architecture  concept  is  central  to  the  creation  of 
enterprise  integration  frameworks.  The  three  architectures  exhibit  a  set  of  characteristics  similar 
to  those  of  the  three  schemas.  Each  architecture  is  a  view  of  the  enterprise  and  although  integra¬ 
tion  is  performed  primarily  in  the  Management  Control  Architecture,  the  other  architectures  must 
be  equally  well  understood.  Taken  as  a  whole,  the  three  architectures  define  an  enterprise,  its 
user  views,  technologies,  and  control  mechanisms.  A  thorough  understanding  of  the  architectures 
is  the  basis  for  the  intelligent  management  of  enterprise  resources,  deployment  of  technology,  and 
management  of  user  requirements.  A  poor  understanding  of  any  one  architecture,  on  the  other 
hand,  could  spell  disaster  for  the  enterprise. 

Business  Architecture 

The  Business  Architecture  is  a  generalization  of  the  External  Schema  in  a  Three  Schema 
Architecture.  As  such,  the  Business  Architecture  is  a  user  view  of  the  enterprise.  The  user  of  a 
business  may  be  a  trading  partner,  a  company  executive,  a  program  manager,  or  a  government 
agency.  In  the  case  of  a  program  manager,  the  user  view  of  the  business  is  the  behavior  needed 
to  support  the  development  of  a  product  or  service.  The  behavior  may  be  the  rapid  development 
of  a  quality  product  (e.g.  a  fuselage,  computer,  airplane,  or  missile)  that  is  easily  produced  and 
supported.  A  financially  oriented  user,  on  the  other  hand,  may  be  looking  for  a  different  be¬ 
havior  expressed  in  terms  of  assets,  earnings  and  profits.  These  external  views  of  the  enterprise 
are  mapped  into  the  internal  systems  and  technology.  The  specific  internal  technologies  are  of 
little  interest  to  the  user  who’s  only  concern  is  the  ability  of  the  enterprise  to  satisfy  his  particular 
requirements. 

Influences  on  the  Business  Architecture  invlude: 

o  Trading  Partner  Relationships,  in  which  an  organization  is  responsible  for  some 
value-added  contribution  to  the  team. 

o  Total  Qualify  Management  which  is  frequently  driven  by  customers  who  desire  a 
high  quality  product  or  service  that  improves  over  time. 

o  Regulatory  Agency  Activities,  including  increasingly  strict  restrictions  on  environ¬ 
mental  protection  and  worker  safety  and  health. 
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o  Global  Competition,  resulting  in  the  need  for  the  rapid  deployment  of  new  tech¬ 
nology  in  high  quality  products  that  are  reasonably  priced  and  fast  to  market 

Technology  Architecture 

The  Technology  Architecture  describes  the  nuts  and  bolts  of  the  organization,  its  net¬ 
works,  people,  product  and  process  technology,  computer  hardware  and  software,  and  other  sys¬ 
tems.  The  Technology  Architecture  defines  and  interrelates  these  items  and  in  doing  so.  defines 
the  mechanisms  used  in  the  execution  of  the  business  processes.  A  technology  architect  has  many 
technologies  to  choose  from.  In  responding  to  a  requirement  to  develop  high  quality  products,  a 
technology  architect  may  choose  a  hierarchical  organization  using  workstations,  local  area  net¬ 
works,  and  relational  database  technology.  The  same  requirement,  on  the  other  hand,  may  be 
mapped  into  a  cross  functional  team  using  Design  for  Manufacture  (DFM)  technology  and  no 
computer  systems.  Various  technologies  can  produce  a  variety  of  results.  Over  time  the  technol¬ 
ogy  architecture  evolves  so  that  it  can  better  support  current  user  requirements  (as  defined  in  the 
Business  Architecture).  The  technology  architect,  like  any  decision  maker,  Im  to  consider  the  - 
available  alternatives  and  make  a  decision  on  the  basis  of  performance,  life  expectancy,  purchase, 
installation,  and  support  costs  of  each. 

Influences  on  the  Technology  Architecture  include: 

o  Organizational  Technology,  ranging  from  steep  hierarchies  to  flat  hierarchies,  task 
focusing  teams,  quality  circles,  and  holarchies. 

o  Design  Technology,  resulting  in  designs  exhibiting  low  cost,  and  high 
producibility,  operability,  and  supportability. 

0  Manufacturing  Process  Technology,  which  ideally  has  a  low  cost  and  a  low 
variability. 

o  Distributed  Processing,  which  lets  independent  computers  share  databases  and 
software  transparently. 

o  Distributed  Database  Management,  which  manages  dau  distributed  over  an  array 
of  geographic  locales. 

o  Layered  System  Services,  which  offer  common  user  interfaces,  application  control, 
data  management,  and  communications  services  across  all  applications  and  comput¬ 
ing  platforms. 

o  Object-Oriented  Development,  which  bandies  graphic  interfaces  more  adeptly, 
leads  to  better  programs  in  less  time,  and  helps  aging  legacy  systems  migrate  up¬ 
ward. 

o  Integrated  Digital  Communications,  which  allow  simuluneous  transmission  of 
voice,  image,  and  digital  data. 
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Management  Control  Architecture 

The  Management  Control  Architecture  enables  the  other  two  Architectures  to  develop  in¬ 
dependently.  It  controls  the  translation  of  Business  Architecture  requirements  into  technology 
solutions  and  provides  support  structures  such  as  standards,  modeling  techniques,  measurement 
techniques,  and  change  control  procedures.  The  Management  Control  Architecture  effectively 
handles  adaptation  to  change  and  exploits  the  potential  of  information  and  other  technologies. 

The  control  architecture  is  especially  powerful  when  combined  with  the  use  of  business 
performance  metrics.  Performance  metrics  are  the  basis  for  the  statistical  management  of  the 
business  and  are  the  cornerstone  of  Benchmarking  and  Business  Configuration  Management 
(BCM).  Through  Benchmarking  and  BCM  the  enterprise  is  modeled,  its  performance  capabilities 
are  understood,  and  its  configuration  improved  in  a  structured  and  orderly  manner.  The  EIF 
supports  the  use  of  BCM  by  providing  a  framework  for  the  integration  and  characterization  of 
business  processes. 

Influences  on  the  Management  Control  Architecture  include: 

o  Layered  Standards,  which  separate  the  definition  and  use  of  standards  according 
to  their  role  in  controlling  functions,  data,  or  technology. 

o  Business  Modeling,  which  uses  a  business  descriptive  language  to  define  the  ele¬ 
ments  and  dynamics  of  the  enterprise  in  a  way  that  allows  simulation  of  manage¬ 
ment  decision  making  and  the  automatic  generation  of  information  system  defini¬ 
tions. 

o  Business  Rules,  which  define  consistent  meanings  for  shared  data  across  all  busi¬ 
ness  processes. 

o  Quality  Function  Deployment,  which  maps  customer  requirements  into  product 
and  process  technologies,  organizations,  information  systems,  and  other  elements 
of  the  technology  architecture. 

0  Three  Schema  Data  Management,  which  separates  the  user  view  of  the  data  from 
the  computer  view  of  it,  and  allows  each  to  evolve  apart  from  the  other. 

0  Asset-Oriented  Methodologies,  which  guide  integration  planning  and  systems  im¬ 
plementation  to  create  reusable  enterprise  assets. 

0  Business  Performance  Metrics,  which  quantify  the  capabilities  of  the  business 
processes. 

The  need  for  enterprise  integration  is  driving  programs  such  as  the  EIF  toward  an  improved  un¬ 
derstanding  of  integration,  its  various  dimensions,  benefits,  cost,  and  role  in  enterprise  improve¬ 
ment.  This  understanding  was  the  basis  of  the  program  positioning  activities  and  the  departure 
point  for  the  development  of  the  Aerospace  Model. 
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Development  of  EIF  Aerospace  Strawman  Model 

The  development  of  the  Aerospace  Strawman  Model  was  the  other  major  study  area  of  the 
EIF  Program.  It's  purpose  was  to  develop  an  industry  oriented  EIF  in  order  to  describe  the 
salient  features  of  manufacturing  operations  within  a  fairly  generalized  environment  that  can 
thereafter  be  extended  to  other  manufacturing  industry  types.  The  aerospace  and  defense  in¬ 
dustry  was  chosen  for  this  focus  to  permit  the  developers  to  draw  upon  their  extensive  knowledge 
and  experience. 

A  summary  of  this  study  and  its  conclusions  follows: 


Presentation  of  Final  EIF  Aerospace  Strawman  (EIFAS)  Development  Tasks 
INTRODUCTION 

Three  interrelated  development  tasks  were  performed  during  the  EIF  contract,  the  first  two  of 
which  were  preplanned,  and  the  last  of  which  was  added  after  the  initial  results  from  the  first 
two  were  jointly  reviewed  by  the  contractor,  the  customer,  and  the  EIF  Working  Group 
(EIFWG).  The  first  task  consisted  of  developing  a  strawman  concept  of  an  enterprise  integration 
framework  that  would  support  the  customer's  and  industry's  efforts  to  improve  ^e  performance 
and  competitiveness  of  the  U.S.  manufacturing  industry,  in  general,  and  of  the  aerospace  in¬ 
dustry,  in  particular,  for  this  first  phase  of  the  development  The  principal  inputs  for  such 
development  were  expected  to  come  from  three  primary  sources,  these  being  from  published  in¬ 
dustry  and  government  initiatives'  work  in  enterprise  and  multi-enterprise  architectural  develop¬ 
ments,  from  the  contractor  team's  own  aerospace  industry  experiences,  and  from  other  industry 
experts  who  would  contribute  through  their  participation  on  the  EIFWG. 

The  second  task  involved  studying  the  recommended  Computer  Integrated  Manufacturing  Open 
Systems  Architecture  (CIM-OSA)  approach  being  developed  by  Amice,  a  European  consortium, 
and  determining  its  compatibility  with  the  findings  and  recommendations  of  the  EIFAS  concept. 
The  principal  objective  of  this  study  was  to  determine  the  appropriateness  of  adopting  the  CIM- 
OSA  framework  as  the  EIF  approach,  while  also  determining  the  differences  in  the  EIFAS  that 
should  be  considered  as  an  enhancement  to  CIM-OSA  if  it  were  adopted  for  EIF. 

After  reviewing  the  CIM-OSA  work,  the  Northrop  team  reached  the  conclusion  that,  while  not  at 
cross  purposes,  the  CIM-OSA  and  EIFAS  approaches  to  the  manufacturing  improvement 
problems  were  sufficiently  different  to  warrant  the  initiation  of  a  third  task  to  aid  in  the  final 
recommendations,  this  being  the  development  of  a  prototype  simulation  model  that  attempts  to 
merge  the  two  directions  being  taken  by  EIFAS  and  CIM-OSA. 

The  EIFAS  approach,  which  is  described  in  the  next  section,  is  to  provide  enterprise  management 
with  a  tool  that  supports  better  understanding  of  their  complex  product  development  operations, 
and,  therefore,  that  supports  more  informed  decision  making  in  developing  and  managing  their 
enterprise's  resources  through  a  process -focused  approach;  i.e.,  through  modification  and 
management  of  those  processes.  Initially  this  was  being  provided  in  the  form  of  a  manager’s 
handbook.  Although  the  CIM-OSA  approach  can  be  applied  to  management  education  and  deci¬ 
sion  support,  it  is  much  more  directed  at  manufacturing  performance  improvement  through  tech- 
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nology  development  and  management,  and  is,  therefore,  being  developed  more  for  use  by  tech¬ 
nologists  than  by  management.  Because  the  CIM-OSA  architecture  has  this  as  the  primary  focus, 
a  more  detailed  and  precise  enterprise  modeling  is  nquired,  and  hence  CIM-OSA  is  also  working 
towards  the  objective  of  developing  an  industry  accepted  enterprise  operations  simulation 
specification  that  could  be  used  to  implement  its  results. 

Both  penpectives  are  important,  and  if  kept  in  proper  balance,  will  both  play  an  important  part 
in  improved  manufacturing  performance  and  competitiveness.  Accordingly,  the  EIFAS  has  al¬ 
ready  undergone  a  migration  from  a  hard  copy  form  to  a  computer-based  simulation,  and  the 
recommended  modeling  approach  has  been  expanded  to  support  both  high-level  management 
modeling  for  learning  and  decision  support,  and  detailed  operations  modeling  for  process  and 
technology  development  and  management 


EIF  AEROSPACE  STRAWMAN  (EIFAS) 
Development  Approach 


The  EIFAS  had  as  its  basic  underlying  objectives  to  develop  a  management  aid  that  was  both 
process-based  and  all  encompassing;  i.e.,  that  would  capture  the  salient  features  and  performance 
drivers  in  the  enterprise,  and  permit  management  to  address  any  of  the  high-level  issues  that  an 
aerospace  executive  is  likely  to  encounter  in  the  highly  complex  and  competitive,  multi¬ 
enterprise  operating  environment  typical  of  modem  weapon  systems  acquisition  and  development. 
Such  issues  are  expected  to  include  business-type  decisions  involving  contract  negotiation  with 
the  Department  of  Defense,  multi-enterprise  trading  partner  relationships  with  subcontractors 
and  suppliers,  and  operations-type  decisions  involving  infrastructure  and  cultural  change.  This 
approach  is  viewed  as  being  quite  different  and  more  advanced  than  the  traditional  approaches  to 
performance  improvement  taken  during  the  1970$  and  19S0s,  wherein  the  principal  attention  was 
directed  at  only  operations-type  improvement,  and  with  these  concentrating  primarily  only  on 
technology  change.  This  approach  has  produced  only  marginal  results  and  has  permitted  foreign 
competition  to  leapfrog  past  the  United  States  in  performance  in  a  number  of  key  and  ever  grow¬ 
ing  areas  of  manufacturing. 

To  understand  the  reasons  for  this,  we  must  understand  what  is  meant  by  the  process-driven  or 
process-oriented  approach.  Processes  are  the  way  activities  are  performed  in  companies  to 
produce  desired  and  definable  results.  Processes  are  made  up  of  the  activities  they  encompass,  the 
resources  that  perform  these  activities,  including  the  information  and  product  that  flows  between 
and  is  created  by  the  activities,  and  the  controls  that  constrain  the  way  the  activities  are  per¬ 
formed  and  the  resources  are  allocated.  Processes  exist  at  all  levels  of  the  enterprise,  ranging 
from  the  highest  levels,  such  as  product  definition,  to  single  person  procedures,  such  as  perform¬ 
ing  a  welding  operation  in  the  shop.  The  existence  of  processes  is  independent  of  organization 
structure,  or  of  how  companies  choose  to  represent  or  build  their  operational  architectures. 

However,  the  management,  facilitation,  and  continuous  improvement  of  processes  is  highly  de¬ 
pendent  on  their  recognition  and  understanding,  and  therefore,  on  how  well  they  are  represented 
to  company  management.  This  is  the  principal  role  of  the  process-oriented  architecture;  i.e.,  to 
enhance  management  understanding  and  control  over  the  company’s  processes,  thereby  paving  the 
way  to  greater  levels  of  enterprise  integration  and  performance  optimization  through  process 
management  and  control,  rather  than  the  traditional  functional  (i.e.,  organizational)  view  of  the 
enterprise.  The  latter  always  results  in  function  rather  than  process  optimization,  and  is  charac- 
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terized  by  enterprise  facilitation  by  function  or  organization,  thereby  creating  the  "islands  of 
automation*  that  typically  result  from  the  functional  approach  to  performance  improvement. 
This  is  the  big  difference  between  the  traditional,  functional  architecture  approach  and  the 
EIFAS  process-oriented  approach. 

At  the  higher  levels  of  enterprise  operations,  processes  are  poorly  defined  and  are,  therefore,  less 
recognizable  and  understood.  Product  definition,  for  example,  is  an  existent  process  in  every 
aerospace  manufacturing  company,  because  design,  analysis,  evaluation,  planning,  and  tooling 
development  are  all  carried  out  Sometimes  their  key  interrelationships  are  treated  with  enormous 
importance  to  the  enterprise,  and  so  product  definition  is  not  only  recognized  as  an  important 
process,  but  it  is  separately  managed  and  facilitated.  In  this  regard,  there  is  a  separate  manager 
appointed  to  manage  the  product  definition  phase  of  a  program,  either  as  a  program  ofHcer 
though  a  matrixed  organization  approach  or  as  a  separately  established  line  organization  with  a 
traditional  organization  manager.  Improvements  to  the  process,  including  changes  and  additions 
to  the  technologies  employed,  are  done  with  respect  to  their  effects  on  the  overall  process  rather 
than  to  a  portion  of  it,  such  as  design  or  manufacturing  planning. 

In  most  cases  when  a  process  such  as  product  definition  is  recognized  and  managed  as  such,  com¬ 
pany  procedures  have  also  been  modified  to  change  the  design,  evaluation,  and  planning  sub¬ 
processes  in  it  from  a  primarily  sequential  processing  to  a  parallel  or  simultaneously  performed, 

.  highly  interactive  and  closely  integrated  operation;  hence  the  name  simultaneous  or  concurrent 
engineering.  The  architecture  that  is  developed  to  represent  such  an  operational  approach  and 
guide  its  facilitation  and  process  improvement,  explicitly  defines  such  high-level  processes  as 
product  definition,  product  delivery,  and  product  support.  Activities  are  grouped  according  to 
their  interrelationships  and  importance  to  the  process  rather  than  according  to  who  "owns”  and 
executes  them. 

In  more  traditional  manufacturing  enterprises,  high  level  processes  such  as  product  definition  are 
barely  recognizable  and  are  modeled  as  a  series  of  loosely  coupled  subprocesses  in  the  enterprise 
architecture.  Design,  analysis,  developmental  and  proof-of-design  testing,  producibility  evalua¬ 
tion,  tooling  development,  and  manufacturing  process  planning  show  up  in  different  (functional) 
legs  of  the  architecture  because  this  type  of  architecture  reflects  the  way  the  company,  and  hence 
its  processes,  is  organized,  managed,  and  facilitated.  Process,  or  more  precisely,  subprocess  op¬ 
timization  is  then  performed  based  on  recognition  and  understanding  of  the  subprocesses  only, 
namely  by  organization  or  function,  to  satisfy  organizational  requirements  and  improve  functional 
performance.  This  is  done  without  real  regard  for  that  of  the  enterprise,  and,  of  course,  in¬ 
variably  results  in  process  and  performance  suboptimization  and  the  proliferation  of  what  has  be¬ 
come  to  be  known  as  "islands  of  automation"  in  the  enterprise. 

For  the  Enterprise  Integration  Framework  Project  to  be  successful,  it  is  important  for  the  adopted 
framework  structure  to  make  this  important  distinction.  It  is  the  best  way,  and  perhaps  the  only 
effective  way,  to  ensure  that  the  framework  will  focus  on  process  and  enterprise  optimization 
rather  than  on  functional  optimization  in  specifying,  developing,  and  implementing  integration 
technologies  into  the  enterprise.  This  will  maximize  the  return  on  investment  in  the  EIF  Program 
and  its  implementation  in  the  using  enterprises,  and  will  help  the  U.S.  manufacturing  industry 
make  the  transition  from  traditional  improvement  approaches,  which  have  produced  only  mar¬ 
ginal  results  over  the  past  several  decades,  to  the  types  of  results  needed  to  achieve  world-class 
manufacturing  performance  and  competitiveness.  The  process -oriented  integration  focused 
framework  must  define  the  processes  and  encompass  and  satisfy  all  process  element  requirements 
including  the  definition,  management,  control  (i.e.,  scheduling,  budgeting,  measurement,  and 
continuous  improvement),  personnel  and  their  training,  information,  and  technologies.  The 
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traditional  approach  has  classically  concentrated  only  on  subprocess  improvement  principally 
through  focus  on  information  and  technology,  and  has  neglected  the  maiugement,  control,  and 
cultural  or  people  issues  involved  with  integration  and  improvement. 


EIFAS  Content  and  Structure 

The  EIFAS  structure  was  determined  from  a  combination  of  (1)  deciding  what  content  or  en¬ 
terprise  operational  features  would  be  required  to  support  both  the  management  orientation  and 
process  basis  sought  for  the  framework,  and  (2)  applying  the  definitions  of  these  features  to 
determine  their  relationship  to  one  another.  Three  distinct  enterprise  operational  features  were 
deterxnined  as  essential  parts  of  the  framework,  these  being 

0  the  individual  enterprise  characteristics  or  elements  that  are  needed  to  describe  a 
manufacturing  enterprise, 

0  the  models  that  relate  the  behavior  of  the  enterprise  in  terms  of  these  constituent  ele¬ 
ments,  and 

0  the  application  scenarios  that  drive  the  models  to  demonstrate  an  enterprise’s  response  to 
one-or-more  stimuli. 

Five  enterprise  elements  were  selected  for  the  strawman  (from  a  more  general  set  developed  for 
the  generic  manufacturing  enterprise  model),  all  relating  specifically  to  the  execution,  ccntrol,  or 
facilitation  of  the  enterprises  processes.  These  elements  are 

(1)  the  processes  themselves, 

(2)  management’s  objectives  stated  in  terms  of  process  performance  expectations  (i.e., 
performance  metrics), 

(3)  management’s  requirements  stated  in  terms  of  the  problems  and  concerns  that  the 
processes  must  address  (i.e.,  issues), 

(4)  the  information  classes  that  describe  the  content  of  the  information  and  product 
flow  created  or  used  by  the  processes,  and 

(5)  the  enabling  technologies  that  describe  the  resource  characteristics  needed  to 
faciliute  the  processes. 

Viewed  from  an  IDEFq  perspective,  the  processes  would  be  equivalent  to  the  activity  descrip¬ 
tions,  the  metrics  and  iuues  would  management’s  control  over  the  processes,  the  information 
classes  would  be  the  process  inputs  and  outputs,  and  the  enabling  technologies  would  be  the 
mechanisms  used  to  execute  the  processes. 

Five  types  of  models  were  initially  recognized  as  contributors  to  describing  enterprise  behavior  in 
terms  of  the  five  selected  enterprise  elements.  These  include 

(1)  simple  element-to-element  relations  that  describe  the  fundamental,  one-on-one 
interdependencies  between  the  enterprise  elements;  matrices  are  used  to  display 
the  results  of  this  (element  relationship)  model  class. 


A-27 


(2)  static,  activity-type  models  that  display  the  composite  of  the  large  number  of  en¬ 
terprise  element  interrelationships  that  occur  in  enterprise  operations;  functional 
block  diagrams  and  IDEFq  models  are  two  of  the  methods  used  to  display  the 
results  of  this  (process)  mooel  class, 

(3)  dynamic,  flow-type  models  that  display  the  composite  of  the  large  number  of 
timing  rules  followed  by  the  process  activities;  critical  path  flow  diagrams  and 
simulation  models  are  two  of  the  methods  used  to  display  the  results  of  this  (flow) 
model  class, 

(4)  cost  models  that  describe  the  combination  of  enterprise  element  characteristics 
needed  to  predict  process  execution  cost;  algebraic  eqtiations  or  statistical  processes 
are  two  of  the  methods  used  to  compute  the  results  of  this  model  class,  and 

(5)  information  models  that  uniquely  describe  the  information  entities  and  their  at¬ 
tributes  that  occur  many  times  over  in  the  various  information  flows  used  in  and 
created  by  the  enterprise  processes;  ID£F|  and  IDEFj^  models  are  used  to  display 
the  results  of  this  model  class. 

There  are  an  endless  number  of  application  scenarios  that  could  make  use  of  the  EIF  in  address¬ 
ing  management’s  various  business  and  operational  concerns  about  their  respective  enterprises. 
Only  a  specific  handful  were  initially  considered  in  establishing  the  form  and  utility  of  the 
EIF  AS,  and  all  were  based  on  exercising  only  the  element  relationship  models  developed  specifi¬ 
cally  for  the  EIF  AS  in  this  strawman  study.  These  scenarios  included  establishing  the  effective 
bounds  for  and  evaluating  the  direction  taken  by  either  enterprise  projects  or  DoD  sponsored  in¬ 
itiatives  dealing  with  manufacturing  infrastructure  development  and  performance  ir  'rovement, 
and  for  predicting  the  cost  of  executing  both  enterprise  and  multi-enterprise  busin  -  processes. 
This  latter  application  was  then  used  as  the  basis  for  the  continued  study  of  the  E.i'AS  in  the 
third  development  task  added  to  the  initial  study  after  evaluating  the  results  of  the  initial  EIFAS 
concept  and  the  comparison  to  CIM-OSA.  This  is  described  in  more  detail  in  Section  IV  of  this 
paper. 

The  three  enterprise  features  included  in  the  EIFAS  were  formed  into  an  overall  framework 
metamodel  by  considering  some  generally  accepted  definitions  of  framework  descriptive  terms, 
these  being: 

0  An  element  is  a  fundamental  building  block  that  represents  the  inherent  properties  that 
are  needed  to  fully  characterize  a  subject  (i.e.,  the  aerospace  manufacturing  enterprise). 
Hence,  the  term  enterprise  element  was  adopted  for  the  set  of  enterprise  characteristics 
that  encompassed  processes,  metrics,  issues,  information  classes,  and  enabling  tech¬ 
nologies. 

o  A  model  represents  the  relationship  between  two  or  more  of  the  basic  properties  of  a  sub¬ 
ject  (i.e.,  an  enterprise).  Hence,  the  term  model  was  adopted  for  the  set  of  enterprise 
relationships  describing  operational  behavior  that  encompassed  element  relationship, 
process,  flow,  cost,  and  information  model  types. 

o  A  reference  model  is  a  schematic  representation  of  all  or  part  of  a  subject  (i.e.,  an 
enterprise).  The  combination  of  the  models  and  the  descriptions  of  their  constituent  ele¬ 
ments  would  therefore  comprise  the  reference  models  of  the  subject  we  call  enterprise 
operations. 
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o  A  scenario  is  a  documented  set  of  actions  performed  to  accomplisb  a  given  objective  or  to 
produce  a  given  result  (i.e.,  a  business  application).  This  describes  the  set  of  application 
scenarios  describing  the  use  of  the  framework  ref^erence  models  to  address  management 
concerns. 

o  An  architecture  is  a  representation  of  one  aspect  of  a  complex  subject  (i.e.,  an  enterprise). 
The  combination  of  a  given  scenario,  addressing  a  specific  aspect  of  business  operations, 
combined  with  the  relevant  reference  models  for  that  application,  would  therefore  com¬ 
prise  the  architectures  of  the  enterprise  framework. 

o  A  framework  is  a  set  of  related  architectures,  each  of  which  expresses  a  view  or  aspect  of 
a  single  complex  subject  (i.e.,  an  enterprise).  The  EIF  is,  therefore,  the  total  set  of  ar¬ 
chitectures  of  reference  model-application  scenarios  needed  to  address  ail  of 
management's  business  and  operational  concerns  as  described  by  the  set  of  enterprise 
issues  included  in  the  enterprise  element  set. 

This  set  of  six  interrelated  definitions  was  used  to  build  the  structure  of  the  EIFAS  metamodei, 
and  the  three  sets  of  enterprise  operational  features  (i.e.,  elements,  models,  and  application 
scenarios)  were  used  to  populate  it.  The  primary  thrust  in  populating  the  initial  strawman  was  in 
issues,  with  several  hundred  issues  being  defined  from  a  handful  of  recognized  expert  sources  on 
enterprise  development  and  performance  improvement,  and  in  the  high-level,  generic  processes 
that  comprise  aerospace  manufacturing  operations.  Initially,  five  (5)  such  high-level  processes 
were  identified,  each  of  which  was  decomposed  into  a  set  of  subprocesses  to  help  show  the  com¬ 
position  of  the  high-level  process,  these  being  enterprise  management,  product  definition, 
product  delivery,  product  support,  and  enterprise  facilitation.  The  full  set  into  which  these  were 
decomposed  consisted  of  twenty-four  (24)  second-level  enterprise  processes,  and  these  too  were 
further  decomposed  one  additional  level  to  better  explain  the  intended  content  of  the  second- 
level  processes.  As  will  be  seen  in  the  next  section  of  this  paper,  this  decomposition  would  have 
to  be  continued  until  the  enterprise's  most  basic  (and  industry  generic)  manufacturing  activities 
were  exposed  to  satisfy  the  CIM-OSA  generic  construct  approach,  if  this  is  adopted  as  the  basis 
for  the  EIF. 

A  schematic  representation  of  the  EIFAS  metamodel  is  shown  in  Figure  2-2.  Neither  the 
proposed  structure  nor  its  content  have  been  subjected  to  the  detailed  industry  critique  needed 
for  a  consensus  acceptance  of  it.  However,  because  it  is  largely  based  on  and  is  not  in  conflict 
with  the  findings  and  recommendations  of  the  prior  industry  studies  referenced  in  its 
development  ,  significant  modification  or  redirection  of  the  recommended  aerospace  framework 
direction  is  not  expected. 


^The  EIF  bibliography  is  included  as  Section  Five  in  this  report 
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FIGURE  2-2- EIF  AEROSPACE  STRAWMAN  (EIFAS)  METAMODEL 


A-30 


COMPATIBILITY  BETWEEN  THE  EIFAS  AND  THE  CIM-OSA  ARCHTTECTURE 


The.  CIM-OSA  Architecture 

The  CIM-OSA  architecnire  is  described  in  terms  of  its  scope  of  application,  its  (specification) 
content,  and  the  constructs  that  implement  this  specification.  CIM-OSA*s  scope  is  described  in 
terms  of  three  dimensions  of  architecture  or  model  development,  these  being  the  level,  type,  and 
view  of  the  model,  respectively. 

Three  model  levels  are  treated,  these  being  the  enterprise  or  requirements  level,  the  intermediate 
or  detailed  design  level,  and  finally  the  implementation  level.  Although  it  has  been  under  way 
for  a  number  of  years  already,  CIM-OSA,  like  the  EIF,  is  considered  to  be  in  the  requirements 
phase  of  its  development. 

Three  levels  of  models  or  architecture  are  used,  ranging  from  the  most  generic  (i.e.,  activities  that 
would  apply  to  any  industry  or  enterprise),  to  partial  (i.e.,  reference  models  that  combine  the 
generic  activities  into  models  that  apply  only  to  specific  industry  segments),  to  particular  (i.e., 
partial  models  that  have  been  tailored  to  represent  the  operations  of  only  a  specific  enterprise 
within  the  industry  segment  covered  by  the  partial  model).  Finally,  four  enterprise  element 
views  are  considered  in  the  CIM-OSA  scope,  these  being  function,  information,  resource,  and  or¬ 
ganization.  These  appear  to  be  closely  ^gned  with  the  basic  IDEFq  modeling  construct,  with 
function  aligning  with  activity,  information  aligning  with  information,  resource  aligning  with 
mechanism,  and  organization  aligning  with  the  activity  constraints. 

From  the  information  made  available  to  the  Northrop  EIF  Team,  it  appears  as  though  each  of 
CIM-OSA’s  construct  specifications  will  be  built  on  a  uniform  format,  in  that  each  will  contain  a 
functional  part,  a  structural  part,  and  a  behavioral  part.  The  functional  part  appears  to  be 
reserved  for  describing  the  inherent  aspects  or  characteristics  of  the  enterprise  element  to  which 
it  refers,  while  the  behavioral  part  is  used  to  describe  the  use  of  the  functional  part,  and  the 
structural  part  describes  the  decomposition  level  or  level  of  detail  of  the  functional  part.  Because 
of  both  the  conceptual  development  and  proprietary  nature  of  the  CIM-OSA  effort,  only  parts  of 
the  construct  specification  are  known  to  the  Northrop  Team.  These  relate  to  function,  resource, 
and  resource  occurrence.  Nothing  is  known  about  information  or  organization  at  this  time.  In 
addition  to  these  specifications,  an  implementation  construct  for  the  function  view  specification 
has  been  developed,  and,  as  discussed  in  the  next  topic,  was  used  to  determine  how  well  the 
IDEFq  based  EIFAS  process  models  mapped  into  the  CIM-OSA  framework. 


The  Comparison  of  the  EIFAS  and  CIM-OSA 

The  comparison  of  the  EIFAS  to  CIM-OSA  took  on  two  perspectives,  one  being  a  detailed  map¬ 
ping  of  the  EIFAS  processes  into  the  CIM-OSA  function  view,  and  the  other  being  a  general 
comparison  of  other,  not  so  well  developed  aspects  of  the  EIFAS  into  the  not  so  well  known  or 
understood  CIM-OSA  architecture.  This  latter  comparison  involved  all  EIFAS  elements  except 
issues,  all  models  except  cost,  and  all  CIM-OSA  model  views  except  organization. 

In  the  detailed  mapping,  the  first  two  process  levels  of  the  EIFAS  were  successfully  mapped  into 
the  CIM-OSA  function  view  constructs.  In  the  first  level,  the  entire  enterprise  was  treated  as  the 
model  domain,  with  five  (5)  business  processes  (enterprise  management,  product  definition, 
product  delivery,  product  support,  and  enterprise  facilitation)  being  identified  in  the  domain. 
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The  domain  interfaces  included  company  owners,  customers,  trade  partners,  governmental 
regulating  agencies,  competition,  the  community,  and  technology  suppliers.  Each  of  the  business 
processes  was  decomposed  into  their  respective  enterprise  activities,  which  numbered  twenty-four 
(24)  in  totaL 

Only  a  sample  mapping  wzs  done  at  the  second  level  of  decomposition  to  demonstrate  the  ap¬ 
proach  that  could  be  taken.  To  do  this,  each  of  the  five  first  level  business  processes  in  the  en¬ 
terprise  domain  was  treated  as  its  own  domain,  and  the  steps  followed  in  decomposing  the  first 
level  were  then  repeated  at  the  second  level.  This  technique  is  a  different  way  of  applying  the 
structural  part  of  the  function  view  standard,  but  gives  the  same  results  as  would  be  obtained 
through  successive  decomposition  of  the  business  processes  into  lower  level  or  ever  increasingly 
finer  subprocesses,  as  is  intended  by  CIM-OSA  in  ultimately  driving  out  the  generic  enterprise 
activities  sought  for  the  generic  architecture  level  of  the  framework. 


Findings 

The  findings  from  the  comparison  is  done  in  three  categories.  The  first  are  the  findings  about 
CIM-OSA  itself.  These  are  that 

(1)  CIM-OSA  information  is  currently  limited  because  it  is  a  proprietary  architecture,  making 
understanding  and  evaluation  of  it  difficult  at  best.  For  the  evaluation  performed  on  this 
contract,  only  portions  of  the  ftinction  and  resource  views  (construct  standards)  were 
known. 

(2)  CIM-OSA  includes  a  behavioral  part  in  its  function  view,  which  provides  a  needed  stan¬ 
dard  to  support  process  simulation. 

(3)  The  CIM-OSA  information  view  appears  to  have  the  same  objective  as  the  IDEFjv 
modeling  methodology;  i.e.,  that  of  supporting  the  development  of  the  conceptual  layer  m 
a  three  schema  information  architecture. 

The  second  set  of  comparison  results  relate  to  the  general  approaches  taken  by  CIM-OSA  and  the 
EIFAS.  In  this  case,  the  CIM-OSA  approach  appears  to  be  being  developed  primarily  as  an  en¬ 
terprise  infrastructure  development  tool.  This  conclusion  is  supported  by  the  following  observa¬ 
tions  about  the  great  amount  of  detail  included  in  and  produced  by  the  CIM-OSA  approach,  and 
includes; 

0  the  development  of  a  specification  for  a  manufacturing  enterprise  simulation  lan¬ 
guage  from  which  a  commercial  product  could  be  spawned  (or  an  existing  one 
modified) 

o  the  development  of  a  "tool  kit*  of  basic  manufacturing  enterprise  elements,  includ¬ 
ing  activities,  information,  resources,  and  management  charters  and  respon¬ 
sibilities  (generic  level) 

o  the  development  of  a  set  of  basic  process  models  based  on  these  elements  (partial 
level),  and  that  can  be  tailored  to  (and  added  to  from  the  tool  kit,  if  necessary)  to 
represent  the  specific  operations  of  the  using  enterprise  (particular  level) 

The  EIFAS  approach  is  quite  different  from  this,  and  has  as  its  objective  an  enterprise  infrastruc¬ 
ture  management  tool.  Accordingly,  its  approach  involves; 
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o  the  development  of  industry  generalized  and  accepted  (by  national  consensus) 
process  models  that  can  generally  represent,  at  a  high  level,  any  aerospace 
enterprise’s  operations,  and  that  "automatically*  tailors  the  results  to  a  specific  en¬ 
terprise  based  on  how  it  is  used  by  the  manager 

o  the  inclusion  of  a  management  oriented,  issue  driven  front  end  that  produces  en¬ 
terprise  response  from  application  scenarios  built  by  the  manager  through  focused 
expression  of  his  specific  problems  and  concerns  (i.e.,  issues) 

o  the  use  of  a  commercially  available,  general  purpose  simulation  program  to  make 
the  EIF  implementation  as  realizable  and  generally  portable  as  possible  to  the 
many  potential,  dispersed,  and  differently  equipped  users  in  the  industry. 

The  third  set  of  comparison  results  relate  to  the  specific  content  of  the  two  architectures.  In 
regard  to  enterprise  elements,  the  two  architectures  appear  to  be  in  substantial  agreement,  with 
only  enterprise  issues  being  omitted  from  CIM-OSA.  In  regard  to  models,  the  two  architectures 
again  are  in  good  agreement,  but  with  some  small  and  potentially  important  differences.  CIM- 
OSA  appears  to  omit  all  reference  to  issues  and  cost  in  their  modeling,  wiu^e  ^he  EIFAS  has  no 
simulation  language  standard  included  to  support  flow-type  modeling.  In  regard  to  framework 
applications,  the  two  architectures  are  in  substantial  agreement  in  stated  objectives,  but  are,  in 
fact,  different  in  what  they  really  support.  CIM-OSA  concentrates  on  supporting  enterprise  in¬ 
frastructure  development  and  improvement,  and  appears  to  ignore  program  and  business  manage¬ 
ment  scenarios.  The  EIFAS  supports  most  management-level  and  some  infrastructure  develop¬ 
ment  and  improvement  scenarios  (related  to  information  systems),  but  tends  to  ignore  all  other 
implementation  scenarios. 

These  comparisons  are  based  on  the  definition  and  understanding  of  the  two  proposed  framework 
approaches  as  such  existed  at  the  time  of  this  study.  CIM-OSA  is  an  evolving  and  only  partially 
understood  concept  with  limited  exposure  to  those  outside  its  development  consortium.  As  more 
detail  is  developed  and  understood,  and  as  the  EIF  strawman  concept  further  evolves,  and  is 
critiqued  and  modified  to  achieve  an  industry  consensus,  the  apparent  differences  between  the 
two  may  lessen  or  go  away  altogether.  This  can  be  facilitated  through  the  cooperative  develop¬ 
ment  of  a  single  framework  that  satisfies  the  combined  objectives  of  Amice  and  the  EIF. 


EIFAS  IMPLEMENTATION:  A  MANAGEMENT-LEVEL  (FEASIBILITY)  SIMULATION 
MODEL 


Purpose 

The  EIFAS  development  task  showed  the  breadth  of  aerospace  operations  information  that  must 
be  organized  and  represented  to  provide  management  with  the  data  base  from  which  to  make 
more  informed  decisions  about  how  and  where  to  change  company  infrastructures  in  improving 
manufacturing  results  and  company  compeutiveness.  The  mapping  and  comparison  task  to 
CIM-OSA  showed  the  EIFAS  concept  to  be  quite  compatible  with  the  CIM-OSA  framework,  as 
well  as  the  potential  usefulness  of  a  simulation  tool  providing  management  with  the  best  means  of 
accessing  the  EIF  data.  These  conclusions  led  to  a  third  development  task  being  added  to  the  ini- 
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tial  EIF  study;  that  of  investigating  the  feasibility  of  the  simulation  model  in  best  presenting  the 
framework  data  to  management.  With  this  in  mind,  the  simulation  task  was  initiated  with  the  fol¬ 
lowing  objectives: 

o  to  demonstrate  the  feasibility  of  developing  a  common  language  tool  that 
facilitates  multi-enterprise  and  multi-disciplined  communications  for  program  op¬ 
timization  and  product  cost,  schedule,  and  quality  improvement 

o  to  determine  the  benefits  of  management-level  simulation  in  organizing  and  com¬ 
municating  enterprise  operational  data  to  management  to  support  their  decision 
making  processes 

o  to  show  the  usefulness  and  applicability  of  the  EIF  aerospace  strawman  model  in 
addressing  management-level  concerns 

o  to  provide  a  basis  for  a  more  detailed  modeling  effort  that  can  expand  the  content, 
accuracy,  and  usefulness  of  the  prototype  for  more  general  manufacturing  en¬ 
terprise  and  multi-enterprise  applications  (the  strategy  for  pursuing  this  is 
described  later  in  this  Section) 


Approach 

The  simulation  model  developed  in  this  task  was  done  as  a  feasibility  prototype  to  demonstrate 
the  EIFAS  model  and  its  usefulness  to  aerospace  managers.  Two  modes  of  use  are  expected. 
These  are  (1)  as  an  education  and  communications  tool  that  supports  management  awareness  and 
understanding  of  cross-functional  processes,  and  (2)  as  a  management  gaming  and  decision  sup¬ 
port  tool  that  permits  them  to  determine  how  they  can  improve  company  performance  and  com¬ 
petitiveness. 

Management  education  and  communications  is  accomplished  by  exposing  different  enterprise  and 
functional  managers  to  what  can  be  accomplished  through  state-of-the-art  infrastructure 
development  and  management  based  on  a  process-oriented  approach,  and  then  by  what  effects 
different  functional  activities  have  on  changing  and  optimizing  the  performance  of  a  program 
and  the  enterprise.  The  simulation  provides  the  basis  for  doing  this  through  inclusion  of  an  in¬ 
dustry  consensus  process-oriented  approach  to  product  development  that  allows  managers  to 
compare  their  company’s  performance  to  what  the  rest  of  industry  can  accomplish,  and  by  per¬ 
mitting  them  to  view  both  their  respective  organization’s  results  and  those  of  the  enterprise.  This 
functional  manager  viewpoint  is  invaluable  in  the  gaming  mode,  where  individual  (functional) 
performance  can  be  altered  and  examined  for  its  effects  on  where  it  counts  the  most;  i.e.,  on  that 
of  the  entire  enterprise.  Such  changes  also  afford  management  with  a  comparative  view  of  how 
the  company  is  expected  to  perform  in  relation  to  the  rest  of  their  industry,  which,  of  course,  in¬ 
cludes  potential  competitors. 

To  demonstrate  these  capabilities,  the  approach  taken  for  the  prototype  included  development  of 
a  finite  set  of  management-oriented  scenarios  that  address  specific  management  concerns  in  con¬ 
trolling  the  business  and  development  programs  of  the  enterprise.  These  scenarios  include: 

0  How  are  program  costs  effected  by  the  prime  contractor’s  implementing  concur¬ 
rent  engineering  to  develop  a  contracted  for  product? 
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o  How  are  program  costs  effected  by  one  or  more  subcontractors  also  implementing 
concurrent  engineering  to  develop  their  portion(s)  of  subcontracted  for  portions  of 
the  product? 

o  How  are  program  costs  effected  by  changes  in  yearly  production  rates,  both  in 
tenns  of  total  levels  and  earlier  or  later  peaks? 

o  How  are  program  costs  effected  by  delays  or  interruptions  at  various  points  in  the 
program's  production  phase? 

o  How  are  program  costs  effected  by  changes  in  customer  requirements  at  various 
stages  of  product  develop  (i.e.,  definition  or  delivery)? 


The  Prototype  Simulation  Model 

The  simulation  model  used  to  demonstrate  the  EIFAS  and  its  management  usefulness  was  based 
on  a  Sun  microcomputer,  and  used  the  G2  general  purpose  simulation  language  package.  The 
model  contained  the  subset  of  the  EIFAS  processes  relevant  to  addressing  the  chosen  management 
scenarios,  which  includes  the  customer,  program  management,  system  engineering,  structure  and 
subsystem  design,  design  evaluation,  auxiliary  product  definition  design  (tooling,  packaging,  sup> 

-  port  and  special  test  equipment,  etc.),  subcontractor  product  definition,  configuration  manage¬ 
ment,  manufacturing  resource  planning  (MRP),  production  purchasing,  subcontractor  and  sup¬ 
plier  product  delivery,  receiving  and  receiving  inspection,  stores  and  kitting,  auxiliary  design 
fabrication  and  assembly,  production  batch  manufacturing,  production  line  flow  manufacturing, 
test,  and  shipping.  The  model  uses  a  pair  of  information  or  product  flow  pipelines  to  intercon¬ 
nect  and  represent  the  closed-loop  relationships  that  exist  between  pairs  of  interacting 
processes/subprocesses.  A  number  of  "busses”  are  used  to  replace  multiple  pipelines,  thereby 
simplifying  the  model  where  either  multiple,  summed  inputs  from  different  generating  processes 
must  be  transmitted  to  another,  single  using  process,  or  where  divided  outputs  need  to  be  dis¬ 
tributed  to  different  using  processes  from  an  input  from  a  single  other  process  that  generates  that 
output.  Finally,  the  model  incorporates  algorithms  that  have  been  generated  to  simulate  the  cost 
results  of 

(1) 


(2) 


findings 

The  lessons  learned  from  this  task  include  those  determined  from  designing,  building,  refining 
(Le.,  evolving),  and  exercising  it.  The  more  salient  of  these  include  the  following: 

o  High-level,  management-type  simulation  modeling  of  complex  manufacturing  enterprises 
can  effectively  be  performed  in  a  top-down  manner,  wherein  high-level  (i.e.,  undecom¬ 
posed)  processes  can  be  simply  described  and  cause  and  effect  relationships  can  be  easily 
modeled  using  simplified  algorithms  that  express  the  results  of  changes  rather  than  how 
the  changed  processes  work  or  how  the  changes  are  implemented. 


changes  in  program  and  major  process  duration  in  production  rate  and  in  produc¬ 
tion  learning  rate,  and 

the  effects  of  contractor  and  subcontractors  independently  choosing  to  implement 
concurrent  engineering  practices  to  perform  the  product  definition  process  and  of 
disruptions  in  the  production  phase  of  the  program. 
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0  More  complex  and  accurate  models  can  be  evolved  from  these  high-level  models  through 
decomposition  of  the  high  level  processes  and  continued  research  into  and  more  precise 
understanding  of  the  cause  and  effect  relationships  between  process  stimuli  and  enterprise 
and  process  performance. 

0  A  number  of  existing  commercially  available  language  packages  appear  to  have  all  the 
necessary  capabilities  to  perform  complex  manufacturing  enterprise  simulations;  however, 
all  contain  their  own  language  peculiarities  and  would  require  a  different  implemenution 
of  the  same  EIF  developed  industry  ‘standard*  process  and  technology  descriptions. 

o  The  relatively  simple,  high-level  management-type  simulations  can  be  performed  on 
microcomputers;  however,  as  such  models  are  expanded  to  accommodate  more  detailed 
simulations  to  satisfy  new  process  design  development  users,  it  is  unlikely  that  such  would 
continued  to  be  the  case.  This  could  require  transition  to  the  use  of  larger  machines  on 
which  to  perform  very  lengthy,  time  consuming  computations,  or  would  require  partition¬ 
ing  and  integration  of  smaller  models  used  to  simulate  partitioned  processes. 

o  The  easiest  part  of  enterprise  and  process  simulation  is  the  construction  of  the  model  on 
the  simulation  tool.  By  far  the  more  challenging,  time  consuming,  and  costly  part  of  the 
task  involves 

o  studying  and  understanding  of  the  complex  cause  and  effect  relationships  that  ac¬ 
tually  exist  in  such  enterprise  operations 

o  designing  the  simulation  model  to  accurately  and  as  simply  as  possible,  algo¬ 
rithmically  represent  these  relationships 

o  compiling  accurate,  discrete  statistics  (Le.,  metrics)  from  enterprise  historical  and 
current  operations  records  with  which  to  populate  ^e  designed  model. 


Strategy  for  Continued  Modeling 


ENTERPRISE  INTEGRATION  FRAMEWORK  -  SIMULATION  MODEL 

£1F  -  SIM 

EIF-SIM  I  is  an  industry  consensus  enterprise  model  which  Northrop  proposes  be 
developed  to  simulate  the  underlying  generic,  high-level  processes  (the  user  will  be  able  to  simu¬ 
late  both  As-Is  and  To-Be  versions  of  each  process)  of  a  typical  manufacturing  enterprise.  The 
To-Be  version  of  the  processes  in  the  model  will  be  optimized  and  integrated  to  reduce  the  cost 
and  schedule,  and  to  improve  the  quality  of  manufactured  products.  This  model  is  employed  as  a 
problem-framing  tool  in  the  development  of  an  enterprise  strategy. 

EIF-SIM  n  is  a  simulation  model  of  the  existing  (As-Is)  operating  environment  of  a 
specific  company.  It  would  be  developed  by  an  individual  company  based  on  EIF-SIM  I.  Like 
EIF  SIM  I,  EIF-SIM  II  is  envisioned  as  a  multi-person  simulation  (business  gaming)  model  used 
to  enhance  communication  between  different  organizational  groups  and  to  promote  mutual  un¬ 
derstanding  of  the  problems  and  objectives  of  these  groups. 

EIF-SIM  I 
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An  important  application  of  simulation  is  as  a  learning  tool  for  complex  decision  making 
which  involves  different  functional  managers.  The  EIF-SIM  I  is  a  multi-person  simula¬ 
tion  tool  which  allows  a  company  to  expose  individuals  to  different  management  roles  and 
perspectives  as  members  of  a  multi-functional  team,  in  order  to  have  them  experience  the 
viewpoint  from  which  other  managers  observe  multi-functional  problems.  Hence, 
multi-manager  simulation  is  a  powerful  tool  to  create  a  common  (language)  basis  for  dis¬ 
cussion  of  the  problems  of  improving  enterprise  process  management. 

This  common  language  also  serves  to  reduce  barriers  between  organizations  (based  on  an 
improved  understanding  of  other  nmnagers*  problems)  and  to  develop  an  enterprise-level 
team,  The  traditional  teams  are  functionally  oriented  (Manufacturing,  Engineering,  etc.) 
and  this  proposed  concept  is  designed  to  develop  enterprise-wide,  multi-functional 
management  teams.  The  EIF  SIM-I  simulation  will  provide  discrete  probabilistic  simula¬ 
tions  of  the  primary  processes  in  a  typical  aerospace  manufacturing  company.  It  will  al¬ 
low  management  team<  to  simulate  both  ”As-Is”  and  *To-Be*  modes  of  execution  of  these 
processes  through  utilization  of  parameters  to  modify  the  processes  to  reflect  current  or 
proposed  operational  policies. 

The  EIF  SIM-I  model  will  allow  executive  management  to  simulate  proposed  'structural’ 
changes  —  such  as  greater  multi-discipline  teaming  and  parallelism,  or  the  conversion  of 
’batch*  processes  to  continuous  flow  processes  —  to  generic  industry  processes,  like  those 
used  today  in  their  companies. 
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EIF  SIM-n  is  a  customized  version  of  EIF-SIM  I,  developed  by  company  technologists  to 
simulate  one  or  more  of  the  company’s  *as-is*  high  level  management  (business)  processes. 
This  effort,  done  with  frequent  executive  management  interaction,  will  develop  *buy-in* 
by  both  executives  and  a  core  team  of  technologists,  laying  the  groundwork  for  real  cul¬ 
tural  change.  In  utilizing  EIF-SIM  II,  a  company  management  group  can  simulate  major 
cross-functional  problems  in  their  company  today,  based  on  todays  processes  and  proce¬ 
dures,  and  evaluate  differences  between  existing  processes  (EIF  SIM-II)  and  the  optimized 
processes  (EIF-SIM  I),  along  with  their  potential  impact  on  the  productivity  of  the  en¬ 
terprise.  Next,  potential  changes  in  the  process  structure  can  be  discussed  and  choices  can 
be  made  with  regard  to  what  changes  to  implement.  Once  having  developed  their  own 
SIM-n  simulation,  and  having  validated  it  with  appropriate  other  company  management, 
the  team  would  proceed  to  modify  their  model  to  reflect  proposed  changes  to  their  cur¬ 
rent  processes  (again,  using  the  EIF  SIM-I  model  as  a  guideline)  and  use  the  simulation  to 
test  the  effects  of  each  change.  This  whole  experience  will  also  help  to  form  the  group 
into  an  integrated  enterprise  team.  (Reference  Figure  2-3) 


SUMMARY 

American  manufacturing  management  has  a  narrowing  window  of  opportunity  in  an  in¬ 
creasingly  competitive  world  business  environment  to  remove  significant  cost  and  flowtime  from 
our  current  process  and  to  improve  our  product  quality.  The  EIF  SIM-I  simulation  could  be  an 
important  tool  to  assist  executive  management  in  this  complex,  risky,  and  politically-charged 
competitive  effort.  There  are  two  types  of  complexity  that  make  enterprise  problems  hard  to 
solve:  the  technological  complexity  and  the  organizational  or  cultural  complexity.  Both  types  of 
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FIGURE  2-3  -  SIMULATION  MODEL  FLOW  CHART 


complexity  need  to  be  addressed  before  any  real  enterprise  policy-making  can  take  place.  The 
EIF-SIM  I  explains  enterprise  process  theory,  while  providing  a  common  Tangxiage"  in  which  en¬ 
terprise  issues  be  simul'*ed  and  discussed.  EIF-SIM  I  is  specifically  oriented  towards  the  or- 
ganizational  problem  of  lu .  — g  different  ’cultures*  within  the  organization  that  all  view  and  af¬ 
fect  functional  problems  differently.  In  EIF-SIM  II,  a  base  is  established  for  a  particular  com¬ 
pany  so  that  the  technical  and  organizational  process  of  policy  making  can  start,  potentially 
resiUting  in  improved  enterprise  management 


2.6  EIF  National  Initiative  Program  Positioning 

This  study  was  roQuested  by  the  EIF  Working  Group  in  order  to  better  understand  the 
relationships  of  a  number  of  government  and  commercial  programs  (which  address  the  issues  of 
enterprise  integration)  related  to  the  objectives  of  the  EIF.  This  is  a  joint  study  by  the  Northrop 
and  IBM  teams  and  the  report  is  Section  Three  of  this  Final  Report. 


2.7  AFX  Cost  Reduction  Scenario  for  the  EIFWG 

This  scenario  was  designed  to  explain  in  a  short  story  form  one  of  the  several  uses  of  the 
Enterprise  Integration  Framework  (FIF)  in  a  specific  business  situation.  The  approach  to 
developing  this  scenario  was  as  follows: 

0  Summary  definition  of  the  Enterprise  Integration  Framework  -  General  explana¬ 
tion  for  those  readers  that  are  not  familiar  with  the  EIF. 

—  Business  Benefits 

EIF  Usage 

o  Industry  Background  -  Orient  the  reader  to  any  unique  characteristics  of  the 
specific  industry  selected,  i.e.  Military  Aircraft. 

o  Enterprise  Context  for  Concurrent  Engineering 

o  Scenario  Premises 

o  Scenario 

o  Summary 

WhUe  this  scenario  was  based  on  a  hypothetical  situation,  the  approach  was  based  on  ex¬ 
tensive  industry  experience  in  similar  situations.  This  experience  was  not  limited  to  dealing  with 
product  cost  reduction  situations  but  also  included  extensive  experience  in  studying  the  underly¬ 
ing  processes  of  an  Aerospace  Manufacturing  Enterprise.  This  report  was  presented  to  the 
EIFWG  in  May,  1990. 


2.9  Mapping  of  the  EIF  Aerospace  Strawman  Model  Onto  the  CIM-OSA  Framework 
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The  purpose  of  this  analysis  was  to  determine  the  applicability  of  the  CIM-OSA 
framework  in  representing  the  content  of  the  Aerospace  Strawman  Model,  The  conclusion  of  the 
study  was  the  CIM-OSA  framework  was  found  to  provide  a  good  structure  into  which  the 
Aerospace  Strawman  Model  could  be  mapped. 


2.10  Conceptual  Definition  of  EIF  Aerospace  Simulation  Model 

T  t.  ^  completed  in  Task  I,  and  Tasks  2.5,  2.7,  and  2.9C  of 

Task  n.  The  study  is  located  in  Section  Four  of  this  Final  Report. 
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EIF  PROGRAM  SUMMARY 


This  program  has  been  a  fascinating  learning  experience  for  all  members.  It  was  felt 
appropriate  to  share  the  more  significant  observations  for  the  benefit  of  those  interested  in  this 
-  subject  matter. 

We  determined  after  our  initial  review  with  the  EIFWG  that  senior  executives  consider 
the  EIF  subject  matter  extremely  complex  and  abstract.  Part  of  the  reason  for  this  reaction  was 
much  of  our  presentations  were  technically  rather  than  management  oriented.  We  concluded  that 
there  are  two  separate  audiences,  management  and  technologists. 

Each  of  these  groups  has  their  own  language  and  a  common  language  does  not  exist.  Con¬ 
sequently,  when  reviewing  this  subject  matter,  use  one  or  the  other  language,  mixing  the  two  may 
result  in  confusion. 

The  Working  Group  emphasized  the  critical  nature  of  identifying  cultural  issues  that 
mitigate  against  change.  We  incorporated  this  advice  into  our  Simulation  Model  Recommendation 
(Page  2). 

We  found  the  CIM-OSA  Framework  to  be  very  comprehensive  in  breadth,  but  equally 
shallow  in  depth.  A  significant  amount  of  work  remains  to  be  done  to  populate  the  cells  in  the 
CIM-OSA  Framework.  Our  recommendation  for  continued  development  of  partial  models 
recognizes  this  situation. 

The  joint  project  with  IBM  on  Program  positioning  demonstrated  the  credibility  of  the 
EIF  Program.  This  project  utilized  the  EIF  process  management  concept  and  clearly  showed  its 
effectiveness. 

In  summary,  EIF  is  credible.  The  work  that  has  been  accomplished  by  both  the  Northrop 
and  IBM  teams  has  made  a  contribution  toward  the  understanding  of  the  complexities  and  mag¬ 
nitude  of  an  Enterprise  Integration  Framework.  There  is  no  doubt  in  our  minds  that  such  a 
framework  is  required. 
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RECOMMENDATIONS 


1.  Simulation.  A  management  oriented  enterprise  simulation  should  be  developed.  This 
simulation  should  be  aerospace  industry  based  with  the  consensus  of  the  major  industry  players. 
The  simulation  should  be  game-oriented  and  utiliae  a  *nser”-based  language  that,  unlike  typical 
simulation  languages,  would  be  meaningful  to  executive  level  management  The  simulation  would 
enhance  the  understanding  of  the  various  functional  components  of  enterprise  performance,  first 
in  a  business-as-usual  environment  and  then  in  an  integrated,  optimized  environment  Such  a 
simulation  would  be  a  powerful  learning  tool  and  reduce  the  cultural  barriers  to  integration. 
Properly  configured,  the  simulation  would  also  be  a  solid  basis  for  risk  analysis,  enterprise  per¬ 
formance  analysis,  and  business  configuration  management  The  simulation  should  include 
reference  models  for  processes  such  as  concurrent  engineering  and  integrated  logistics  support 
and  should  be  offered  to  CIM-OSA  for  inclusion  in  their  framework  as  validated  partial 
(aerospace)  models.  (Reference  Report  -  EIF  Aerospace  Strawman  Prototype  Simulation  Study  - 
£IF  Task  2.10  and  Section  Four  -  EIF  Aerospace  Strawman  Model). 

2.  Coordination  of  Integration  Programs.  There  is  a  dramatically  increasing  number  of  in¬ 
tegration  programs  currently  underway.  Many  of  the  programs  are  working  on  the  same 
problems  with  little  understanding  of  their  contemporaries.  There  should  be  established  a  coor¬ 
dinating  body  for  these  integration  programs.  National  initiatives  such  as  CALS,  PDES,  and 
SEMATECH  should  be  included  along  with  other  comparative  key  industry  and  academic  efforts. 
In  support  of  the  national  coordination  body.  Some  entity  should  extend  the  EIF  program 
positioning  approach  to  deal  with  detailed  program  issues,  integration  methodologies,  and  techni¬ 
cal  specifics.  The  detailed  program  positioning  approach  should  be  offered  to  the  coordinating 
body  as  a  tool  for  the  integration  of  the  various  national  and  international  initiatives. 

A  focused  development  and  coordination  activity  is  recommended  in  the  area  of  product  data  in¬ 
tegration.  This  area  is  vital  to  any  manufacturing  enterprise,  where  the  data  used  to  define, 
produce,  and  support  a  product  has  to  be  made  available  to  trading  partners,  suppliers,  govern¬ 
ment  agencies,  and  a  host  of  other  organizations.  Product  data  integration  is  a  unique  oppor¬ 
tunity  for  the  EIF  because  a  significant  amount  of  work  has  been  done  in  the  detailed  develop¬ 
ment  of  product  data  integration  technology.  The  PDES  activities  in  particular  provide  a 
springboard  for  the  demonstration  of  true  product  data  integration.  Two  actions  are  required. 
Current  PDES  activities  in  the  development  of  a  product  description  language  should  be  focused 
and  supported,  and  a  research  environment  established  with  the  goal  of  achieving  a  PDES  Level  4 
implementation  in  3  years.  (Reference  Report  -  EIF  National  Initiative  Program  Positioning  - 
Task  2.6  and  Section  Three  -  EIF  Concepts). 

3.  Joint  Developinent  with  CIM-OSA  A  government  agency  should  become  a  focal  point 
for  the  U.S.  participation  in  the  development  of  CIM-OSA.  It  should  represent  the  position  of 
the  numerous  U.S.  integration  initiatives  lacking  the  means  to  participate  individually.  It  should 
continue  an  involvement  in  CIM-OSA  to  ensure  that  the  EIF  requirements  and  lessons  learned  are 
undentood  by  the  CIM-OSA  membership.  The  EIF  requirements  for  an  Enterprise  Description 
Language  should  be  defined,  developed,  and  offered  to  CIM-OSA  as  a  building  block  in  the  con¬ 
struction  of  their  business  description  language.  The  development  of  an  approach  to  high  level 
business  integration  should  be  undertaken  jointly  by  CIM-OSA  and  the  U.S.,  one  of  the  goals  of 
this  effort  should  be  the  development  of  more  of  a  management-styled  front  end  to  CIM-OSA,  as 
opposed  to  the  process  and  technology  development  and  implementation-oriented  interface  now 
planned.  Properly  orchestrated,  these  coordination  actions  could  aid  the  filling  of  the  rooms  of 
the  CIM-OSA  house  possibly  with  the  validated  EIF  aerospace  models  and  constructs.  Two 
specific  tasks  are  recommended  in  this  regard,  these  are: 
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A  team  of  system  experts,  representing  a  reasonable  cross-section  of  the  aerospace 
i^ufacturing  industry  and.  therefore,  a  possible  first  cut  at  an  industry  consensus, 
should  be  assembled  and  charged  with  the  responsibUity  for  accumulating  and  selecting 
the  best  and  most  representative  of  the  aerospace  industry’s  large  existing  inventory  of 
TCFa  manufacturing  enterprise  models,  transforming  them  into  the  beginnings  of  the 
CTM-OSA  constructs,  and  then  completing  these  with  the  auxiliary  behavior  information 
absent  from  the  ID£F  methodology. 

A  team  of  information  analysts  similarly  formed  should  likewise  study  the  requirements 
of  tte  CIM-OSA  information  view  and  determine  the  applicability  of  the  IDEF.y 
methodology  to  satisfy  them,  and  then  develop  whatever  modifications  to  the  methodol¬ 
ogy  found  necessary  and  appropriate  by  tbam 


m  recommended  actions  in  the  above  areas  are  a  logical  extension  of  the  work  performed  in  the 
contract  and  will  advance  key  aspects  of  enterprise  integration.  The  U.S.  government  is  the 
correct  agency  to  be  sponsoring  these  activities  since  it  alone  is  capable  of  pulling  off 
on  this  scale.  The  first  step  has  been  taken  but  there  are  many  more  that  must  follow 


integration 
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INTOODUCnON 


A  number  of  government  and  commercial  programs  address  die  issues  of 
enterprise  integration  from  a  variety  of  standpoints.  The  IBM  and 
Northrop /D.  Appleton  Co.  Enterprise  hitegration  Framework  (EIF)  teams 
studied  these  programs  to  better  imderstand  how  their  obj'ectives  related  to 
those  of  the  EIF.  This  report  documents  the  findings  of  that  activity  and 
represents  the  viewpoint  of  both  teams.  This  program  positioning  exercise 
was  a  highly  successful  first  step  in  defining  the  state  of  the  various 
integration  activities  and  in  developing  a  reference  frame  for  characterizing 
and  potentially  integrating  them. 

The  programs  included  in  the  survey  are  sponsored  and  supported  by  a  wide 
range  of  industry,  government,  and  academic  organizations.  Collectively 
these  programs  represent  a  national  effort  addressing  enterprise  integration. 
The  specific  programs  included  in  this  evaluation  are  the  following. 

•  Automated  Airframe  Assembly  Program  (AAAP) 

•  CAM-I  Computer  Integrated  Enterprise  (CIE) 

•  CAM-I  Cost  Management  Systgn  (CMS) 

•  CAD  Framework  Initiative  (CFI) 

•  Computer  Integrated  Manufacturing  -  Open  Systems  Architecture 

(CIM-OSA) 

•  DoD  Computer  Aided  Acquisition  and  Logistics  Support  (CALS) 

•  DARPA  Initiative  in  Concurrent  Engineering  (DICE) 

•  Geometric  Modeling  Applications  Interface  (GMAP) 

•  GM  -  CAD,  CAE,  CAM,  OM  (C4)  Program 

•  Engineering  Information  System  (EIS) 

•  Product  Data  Exchange  Specification  (PDES) 

•  Purdue  CIM  Reference  Model 

•  Rensselaer  Polytechnic  Institute  (RPI)  CUM  Program 

•  SEMATECH  CIM  Architecture 

There  is  a  huge  body  of  material  associated  with  each  of  these  programs.  This 
comparison  is  a  top  level  condensation  of  that  material.  Its  purpose  is  to 
position  the  programs  relative  to  a  set  of  criteria  agreed  upon  by  the  IBM  and 
Northrop /D.  Appleton  Co.  teams.  The  criteria  were  chosen  for  their  ability  to 
characterize  the  programs  and  differentiate  between  them.  They  are  the 
following: 

a.  The  levels  of  the  organization  addressed  by  the  programs. 

b.  The  coverage  of  multiorganizational  enterprises. 

c  The  variety  of  modeling  tools  and  methods  associated  with  the 
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programs. 

d  The  product  life  cycle  phases  addressed  by  the  programs  (Le. 
requirements,  design,  production,  and  support.) 

e.  The  impact  of  the  programs  on  the  enterprise  ’’regeneration 
process"  (as  opposed  to  the  product  life  cyde). 

f.  The  current  status  Oevel  of  definition)  of  the  programs. 

g.  The  approach  of  the  programs  to  technology. 

No  single  chart  can  address  all  of  these  issues  in  a  comprehensible  way,  so  the 
issues  were  divided  into  a  set  of  charts  which,  when  taken  together,  provide  a 
picture  of  the  individual  programs  and  the  relationships  between  them.  The 
resultant  charts  are  explained  in  the  following  discussion. 


CHART  DESCRIPTIONS 


1.  Enterprise  Viewpoints  Charts  (Product  Life  Cvcle  vs.  People  &  Orgs.) 

A  typical  manufacturing  enterprise  is  strongly  influenced  by  the  programs  in 
which  it  is  partidpating.  For  this  reason  it  is  important  to  imderstand 
integration  issues  in  the  context  of  the  product  life  cyde.  This  chart  format  is 
used  for  that  purpose.  It  positions  the  programs  relative  to  their  impact 
within  and  between  organizations  and  aaoss  the  product  life  cyde.  The 
organizational  axis  is  composed  of  the  following  internal  and  external 
organizations  and  relationships. 

Internal 
Executive 
Manager 
Analyst 
Flaimer 

Users  (men  &  machines) 

The  simplified  product  life  cyde  on  the  horizontal  axis  consists  of 
Requirements,  Design,  Production,  and  Support.  The  individual  programs 
were  mapped  onto  the  space  defined  by  the  two  axes.  The  composite  chart 
indicates  ^e  number  of  programs  addressing  each  area.  Areas  with  a 
sigiuficant  amoxmt  of  program  overlap  are  candidates  for  cooperation,  and 
areas  with  little  emphasis  are  potential  candidates  for  future  development 
work. 


External 
Customers 
Trading  Partners 
Suppliers 
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The  Enterprise  Viewpoints  summary  chart  (Figure  1)  is  most  easily  examined 
in  two  steps.  The  top  half  represents  the  coverage  of  issues  within  or 


ENTERPRISE  VIEWPOINTS 


Program  Positioning 


Customer 


Trade  Partner 


Supplier 


Internal 


EXECUTIVE 


MANAGER 


ANALYST 


PLANNERS 


USERS 


design 


support 


•  Major  focus  is  information  analyst  perspective 

•  Little  focus  is  on  customers,  execs,  and  users 

•  Little  focus  on  requirement  and  product  support 


Figure  1  >  Enterprise  Viewpoints  Summary 

between  organizations.  The  data  indicates  that  the  majority  of  integration 
programs  have  focused  primarily  on  internal  issues  and  much  less  on 
customers,  trading  partners,  and  suppliers.  The  lower  half  of  the  chart  is  an 
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explosion  of  the  "internal”  category  foimd  on  the  upper  half.  It  indicates  that 
the  vast  majority  of  programs  are  focused  on  "information  analysts”  and  not 
on  management  or  other  end  users.  Both  the  upper  and  lower  halves  of  the 
chart  indicate  a  focus  on  the  design  and  production  phases  of  the  product 
lifecycle,  with  much  less  emphasis  on  requirements  and  support  One 
exception  to  this  general  trend  is  CUE  (see  Appendix  A-2).  'nds  chart  suggests 
both  a  wide  number  of  users  and  a  focus  that,  although  it  does  overlap  into 
design,  emphasizes  requirements.  Other  individual  program  charts 
summarized  in  Figure  1  are  also  fotmd  in  Appendix  A. 

2.  General  Focus  CTharts 

While  integration  is  often  a  function  of  the  product  life  cycle,  it  is  also  a 
function  of  the  enterprise  "regeneration  process"  and  must  be  well 
imderstood  in  that  context  The  process  by  whidi  an  enterprise  is  regenerated 
involves  an  tmderstanding  of  the  internal  and  external  environments  wd  a 
corresponding  set  of  adjustments  to  the  business  configuration  (s3rstems, 
people,  etc).  Enterprise  regeneration  is  the  basis  of  the  continued  survival 
and  well-being  of  the  enterprise  and  is  typically  independent  of  any  one  single 
program.  This  chart  format  is  used  to  position  the  programs  with  respect  to 
their  impact  on  this  process,  which  is  defined  in  terms  of  following  steps. 

a.  The  development  of  descriptive  models  (process,  activity, 
information,  etc.) 

b.  The  development  of  enterprise  systems  (in  this  case  open  systems 
&  Open  System  Architectures  or  OSAs) 

c  The  operation  of  the  enterprise  (in  which  the  systems  are  built, 
installed,  maintained,  improved  and  (ultimately)  retired). 

The  enterprise  systems  which  are  the  subject  of  this  discussion  are  not  limited 
to  computer  and  information  systems.  Instead,  they  include  all  of  the  systems 
required  to  support  the  full  range  of  enterprise  processes.  This  means  that  an 
open  system  is  defined  in  terms  of  the  practices  and  procedures,  physical 
interconnects,  human  interfaces,  and  mformation  and  commuiucations 
systems  required  for  integration.  These  systems  are  used  in  the  support  of  one 
or  more  of  the  following  enterprise  "areas." 

a.  Management  (Planning,  Organizing,  Staffing,  and  Control) 

b.  Operations  (Execution) 

c  Support  (Providing  &  maintaining  the  necessary  environment  for 
Management  and  Operations) 

The  charts  indicate  the  areas  in  which  the  programs  are  addressing 
technology.  The  individual  program  charts  are  found  in  Appendix  B.  The 
summary  chart  (Figure  2)  indicates  the  overlaps  among  programs  which, 
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again,  are  candidates  for  coordination.  The  greatest  overlap  is  in  open 
systezns  architectures  in  the  enterprise  operations  area.  Ahnost  every 
program  is  adapting  or  developing  some  portion  of  an  open  S3^tems 
architecture.  AAAP  (Appendix  B-2),  is  a  dear  example  of  a  program  forcused 
wholly  in  the  operations  area.  The  management  and  support  areas,  on  the 
other  hand,  are  the  focus  of  little  attention.  A  more  detailed  treatment  of  the 
technology  associated  with  the  various  programs  is  contained  in  the 
following  section. 

GENERAL  FOCUS 
Program  Positioning 


MANAGEMENT 

OPERATIONS 

SUPPORT 

Modets  OSA  Oparating 

DESCRIBE  ARCHITECTURE  APPLICATIONS/ 

ENVIRONMENT 


IZZl  1-2 
CZD  3-5 
imm  B* 

•  Focus  is  on  operations  (not  on  management  or  support) 

•  CIM-OSA  concepts  address  total  envelope 

•  Most  programs  address  necessary  breadth  (across  chart) 


Figure  2  •  General  Focus  Summary 
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3.  Technology  Approach  Charts 

These  charts  are  the  basis  of  the  Technology  Considered"  chart  described  in 
the  previous  section.  The  Technology  Approach  charts  identify  ♦he  specific 
technologies  addressed  by  the  progrants.  The  individual  charts  each 
program  are  found  in  Appendbc  C  and  are  summarized  in  Hguic. ;  The 


Figure  3  -  Technology  Approach  Summary 
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technology  is  defined  in  terms  of  whether  it  is  being  developed,  adapted,  or 
used  "off  the  shelT  by  the  programs.  The  chart  also  identifies  those 
technologies  which  are  being  developed  into  new  products  by  die  various 
programs.  The  technologies  are  grouped  into  the  areas  of  design  and 
operations  in  the  following  manner. 

Design 
Methodology 
Simulation 
Models 
Languages 
CASE 
OSA 

These  charts  identify  the  technologies  diat  are  of  interest  to  a  program  that  are 
not  actually  being  developed  by  that  program.  Programs  such  as  CALS  are 
focused  on  the  a^ptation  and  use  of  esdsting  technologies  instead  of  the 
creation  of  new  ones.  This  distinguishes  CALS  from  a  program  sudi  as  the 
Automated  Airframe  Assembly  Program  (see  Appendices  C*2  and  C-4),  in 
which  a  significant  amount  of  new  technology  is  being  developed.  The 
summary  chart  in  this  series  indicates  that  the  development  of  technology  is 
greatest  in  four  specific  areas.  These  areas,  namely  Methodology,  Open 
Systems  Architectures,  Communication  Control,  and  Applications  are  strong 
candidates  for  coordination  across  programs.  Areas  of  overlapping 
technology  use  and  product  development  are  also  identified  on  the  summary 
chart,  but  are  of  less  interest,  because  of  a  smaller  potential  for  conflict. 

The  lack  of  product  development  in  many  of  the  technical  areas  is  not 
necessarily  a  cause  of  concern.  Although  many  of  the  surveyed  programs  are 
not  developing  products,  it  is  entirely  possible  that  the  technology  is  being 
transitioned  to  other  agencies  that  perform  the  actual  packaging  and 
productization. 


Operations 

Communications  Control 
Information  Control 
Process  Control 
Human  (Interfaces) 
Machine  (Technology) 
Applications 


4.  InformaHon  Group/Process  Matriz  Charts 

These  charts  position  the  programs  from  an  information  and  process 
standpoint.  The  processes  are  those  used  by  the  people  in  an  enterprise  to 
design,  build,  and  support  the  product,  to  manage  these  "doing"  processes, 
and  to  support  the  enterprise  processes  ivith  the  resources  that  they  require. 
The  information  groups  are  those  categories  into  which  all  data  in  a  typical 
manufacturing  organization  can  be  sub-divided. 
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Each  program  is  mapp6d  onto  an  individual  chart.  The  individual  charts  are 
found  in  Appendix  D.  The  individual  chart  for  the  CAM*1  CMS  program 
(Appendix  D-6),  for  example,  indicates  a  focus  on  financial  management 
information  (horizontal  axis)  across  all  but  three  of  the  enterprise  process 
areas  (verticd  axis).  Each  individual  program  has  a  different  process  and 
information  focus  and  a  different  range  of  enterprise  coverage. 


SUMMARY  INFORMATION  GROUP/PROCESS  PLANNING  MATRIX 
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Primary  focus  in  product  arxf  mamifacturing  data 

Over  50%  of  areas  not  addressed  by  any  of  the  surveyed  programs 

Little  work  In  support  areas  and  business  management _ 


Figure  4  •  Information  Group/Process  Matrix  Summary 


The  summary  chart  (Figtire  4)  is  a  composite  of  the  individual  program 
charts.  It  in^cates  the  overlap  across  programs  which  is,  not  surprisingly, 
greatest  in  the  information  management  and  product  information  areas.  The 
overlaps  would  be  even  more  significant  if  programs  such  as  the  Electronic 
Data  Interchange  Format  (EDIF),  VHSIC  Hardware  Description  Language 
(VHDL),  and  other  similar  programs  were  mapped  into  the  matrix.  Both 
VHDL  and  EDIF,  for  example,  would  add  another  box  to  the  already  crowded 
intersection  of  product  development  (vertical  axis)  and  product  iziformation 
(horizontal  axis).  In  contrast  to  these  overlaps,  half  of  the  enterprise  areas  are 
not  addressed  at  all  by  any  of  the  integration  programs  included  in  this 
survey.  Qearly,  the  message  in  this  chart  is  Aat  the  majority  of  the  current 
integration  programs  are  focused  on  a  small  subset  of  the  enterprise,  while 
the  majority  of  the  enterprise  is  left  unexamined. 
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5.  Program  Lpvgl  of  Definition  Charts 

The  program  level  of  definition  is  an  important  measure  of  the  forward 
progress  of  the  programs.  When  used  in  concert  with  the  scoping  charts 
(Figures  1  -  4),  the  result  is  a  unified  picture  of  a  program’s  intent  and  detail. 
These  charts  position  the  programs  in  terms  of  their  current  status  in  three 
areas: 

a.  Architecture  (Defining  the  program  structure  and  direction) 

b.  Modeling  (Providing  the  detailed  description  of  the  environment) 
c  Integrated  Infrastructxirc  (The  physical  systems  supporting  a.  &  b.) 

The  current  program  status  is  defined  in  terms  of  the  following  phases. 

Concept  Requirements  identification,  general  design  concept 
investigation  and  modeling  resulting  in  a  preferred 
alternative. 

Design  Development  of  the  preferred  alternative  into  detailed 
specifications,  interface  specs,  and  demonstrated  models. 
Implementation  Operational  pieces  of  the  design  are  implemented. 
Installation  Fully  operational  design  is  implemented. 

The  level  of  definition  charts  (Figures  5  and  6)  indicate  that  many  of  the  more 
focused  programs  (e.g.  GMAP  and  AAAP)  are  closer  to  implementation  than 
the  programs  with  a  broader  scope  (e.g.  CAM-I QE  &  QM-OSA).  This 
indicates  a  potential  opportunity  for  cooperation  and  joint  development  with 
one  or  more  programs  with  a  similar  intent  to  that  of  the  EIF.  A  concept 
phase  program  such  as  CIM-OSA  is  a  strong  candidate  for  a  joint  activity  in 
which  the  Air  Force  and  aerospace  industry  perspectives  could  be  used  in  the 
definition  of  the  overall  approach  and  execution  of  the  program. 
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Pigure  5  >  Program  Level  of  Definition  (Part  1) 
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Figiire  6  -  Program  Level  of  Definition  (Part  2) 
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CONCXUSIONS 


A  number  of  conclusions  have  been  suggested  in  die  body  of  the  text  and  will 
not  be  repeated  in  this  section.  Hiis  section  deals,  instead,  wifli  general 
observations  about  the  comparison  results  and  the  cooperative  process  used 
to  arrive  at  them. 

The  first  observation  relates  to  the  difficulty  in  concisely  and  accurately 
defining  integration  programs.  "Boxing"  an  initiative  such  as  CALS  or  PDES 
is  a  subjective  exercise  in  which  the  current  status  of  the  effort,  its  future 
intentions,  the  current  and  projected  funding  levels,  stated  and  implied 
objectives,  and  a  number  of  other  factors  must  all  be  considered.  Fortunately, 
the  actual  positioning  of  the  program  is  less  important  than  the 
communication  initiated  in  the  process.  This  communication  is  a  powerful 
integrating  force  and  clearly  needs  to  be  continued  in  the  future. 

Even  more  fundamental  than  characterizing  the  integration  programs  is 
imderstanding  integration  itself.  More  than  once,  the  EIF  team  was 
compelled  to  return  to  the  basics  of  enterprises,  integration,  and  processes  in 
order  to  imderstand  the  issues.  The  process  view  of  integration,  in  particular, 
was  effective  in  identifying  and  imderstanding  integration  issues.  The 
process  view  of  enterprise  integration  is  based  on  the  realization  that  the 
enterprise  processes  are  the  means  by  which  enterprise  products  and  services 
are  designed,  produced,  sold,  and  supported.  Continuous  improvement  of 
products  and  services  is  achieved  through  the  improvement  of  enterprise 
processes  which,  in  turn,  are  frequently  improved  through  (more  effective) 
integration.  Tlas  view  allows  the  issues  of  human,  legal,  procedural, 
physical,  and  information  integration  to  be  dealt  with  on  a  common  footing. 
These  basics,  better  defined  as  a  result  of  the  EIF,  are  a  key  to  the  integration 
process. 

A  final  observation  is  that  a  set  of  recurring  themes  is  evident  throughout  the 
various  positioning  charts.  There  is  an  emphasis  on  the  modeling  of  the 
business,  the  creation  and  use  of  functional  and  data  standards,  and  the 
development  of  a  "management  control  architecture"  as  the  basis  of 
enterprise  integration.  This  approach  is  not  a  revolutionary  one  but  rather  a 
reinforcement  of  the  values  advanced  by  the  DoD  and  MANTECH 
organizations  in  the  past  decade.  As  this  work  is  performed  it  becomes 
increasingly  important  that  there  be  cooperation  and  integration  across  the 
various  programs  in  order  to  maximize  their  benefits.  The  EDF  program 
positioning  exercise  and  related  work  can  be  the  basis  of  an  umbrella  under 
which  these  integration  efforts  are  understood,  related  to  other  initiatives 


1C-EJG^3-05(WX)6 


OACOM 

0.  Applaton  Company,  Inc. 


J:ir  i^rogram  Positioning 


July  19, 1990 


(e.g.  Concurrent  Engineering  and  Total  Quality  Management),  and  ultimately 
us^  to  more  effectively  advance  the  interests  of  the  Air  Force,  DoD,  and 
industry. 
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Appendix  A 
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EIF  AEROSPACE  STRAWMAN  MODEL  SIMULATION  STUDY 


PURPOSE 

The  purposes  of  the  EIF  aerospace  strawman  model  prott^yinog  effort  are 

o  to  demonstrate  the  feasibility  of  developing  a  common  language  tool  facilitates  mnlti-enterprise  and 
multi-disciplined  communications  for  program  optimization  and  product  cost,  schedule,  and  quality  im¬ 
provement 

o  to  determine  the  benefits  of  management-level  simulation  in  organizing  and  entnninni raring  enterprise, 
operational  data  to  management  to  support  their  decision  maVing  processes 

o  to  show  the  bq  j  applicability  ot  the  EIF  aerospace  strawman  model  in  addresang  Tnanygrmmt. 

level  concerns 

o  to  provide  a  basis  for  a  more  detailed  modeling  effort  that  can  expand  the  eoateat,  accuracy,  and  useful¬ 
ness  of  the  prototype  for  more  general  manufacturing  enterprise  and  multi-enterprise  applications 


APPROACH 

The  basic  approach  taken  in  developing  the  simulation  prototype  was  to  develop  a  representative  set  of  real, 
aerospace  management  business-  and  program-oriented  concerns,  and  then  determine  if  a  simulation  model 
could  be  developed  (based  on  the  Northrop  EIF  aerospace  lawman)  that  could  adequately  address  all  or  a 
selected  subset  of  these  concerns;  i.e.,  build  the  minimum  simulation  model  of  the  enterprise  that  could  address 
the  specific  scenarios  or  concerns  selected  for  the  prototype  demonstration.  This  approach  permitted  the 
development  of  a  working  prototype  in  the  very  limited  time  available  to  the  effort  It  had  the  disadvantage  of 
not  yielding  a  model,  either  in  depth  or  breadth,  that  could  be  used  to  address  more  detailed  questions  or  con¬ 
cerns  of  the  user  managers,  or  of  being  extended  to  scenarios  that  were  beyond  the  programming  goal  Those 
covered,  however,  were  felt  to  be  sufficiently  representative,  and  would  require  modeling  and  of 

enough  the  aerospace  strawman  to  be  indicative  of  whether  the  simulation  could  be  effective  and  produce  the 
desired  results. 

The  approach  taken  for  use  of  the  simulation  can  be  categorized  into  three  basic  steps,  these  being; 

L  To  display  to  the  user  all  of  the  built-in  model  characteristics,  mcluding  descriptions  of  the  included  en¬ 
terprise  processes,  process  relationships,  and  baseline  (industry  generalized)  metrics  and  assumptions,  the 
latter  induding  overhead  rates,  hourly  compensation  rates,  nominal  processing  times  and  time  standvds, 
and  the  like.  The  user  will  have  the  option  at  this  poiiU  of  modifying  any  of  these  metrics  to  better  reflect 
their  own  enterprise’s  operations. 

2.  To  display  all  of  the  program  spedCc  and  dependent  parameters  that  the  user  must  supply,  such  as  yearly 
production  rates,  length  of  product  definition  and  delivery  processes  (Le,  program  length  and  milestones), 
customer  mandated  or  caused  production  breaks,  and  the  like. 

3.  To  exercise  the  model,  display  the  results,  and  permit  the  user  to  reinitiate  the  simulation  after  modifymg 
any  of  the  enterprise  or  program  parameters  in  building  Vhat  iP  scenarios  to  see  the  effects  of  these 
changes  on  program  and  enterprise  performance.  Initially,  such  performance  will  be  restricted  to  cost,  but 
will  eventually  be  extended  (in  follow-on  efforts)  to  mdude  schedule  and  output  quality.  For  the  cost  per¬ 
formance,  the  displayed  outputs  will  include  total  program  cost,  individual  process  cost  (divided  into  direct 
and  indirect  charges),  average  cost  of  delivered  unit,  total  cost  of  all  units  to  date,  and  cost  of  the  last  unit. 


MANAGEMENT  SCENARIOS 


A  aiimber  of  maoagefflent'level  business  and  program  scenarios  were  evaluated  and  considered  for 

use  in  the  simulation  prototype.  A  subset  of  these  was  selected  for  current  use  based  on: 

a.  the  judged  relative  importance  of  the  scenario  0^  potential  problem)  on  enterprise  business  and 
program  performance, 

b.  how  well  the  cause  and  effect  relationships  pertaining  to  the  cost  issues  eadi  could  be  understood  and 
simply  described  for  use  in  the  high-level,  simplified  type  of  prototype  being  constructed,  and 

c  the  amount  of  time  available  to  perform  such  modeling  for  this  abbreviated,  demonstration  effort 

Based  on  these  criteria,  five  scenarios  were  used  to  guide  the  prototype  development;  Le.,  depending  on 
icenario  and  the  algorithm(s)  or  equations  developed  for  h,  specific  enterprise  and  program  processes 
parameters  were  added  to  the  simulation  model  to  permit  it  to  address  the  scenario.  The  following 
scenarios  were  choseru 

L  What  are  the  program  effects  of  the  prime  contractor  implementing  concurrent  en^eeting  to 
develop  a  contract^  for  product? 

2.  What  are  the  program  cost  effects  of  one  or  more  subcontractors  also  implementing  concurrent  engineer¬ 
ing  to  develop  their  portion(s)  of  subcontracted  for  portions  of  the  product? 

3.  How  are  program  costs  effected  by  changes  in  yearly  production  rates,  both  in  terms  of  total  levels  and  ear¬ 
lier  or  later  peaks? 

4.  What  is  the  cost  effect  of  program  delays  or  interruptions  at  various  points  in  the  program's  production 
phase? 

5.  What  is  the  program  cost  effect  of  changes  in  customer  requirements  at  various  stages  of  product  develop 
0.e.,  definition  or  delivery)? 


MODEL 

The  simulation  model  developed  for  the  EIF  prototype  is  based  on  a  portion  of  the  Northrop  aerospace  straw- 
man  needed  to  adequately  represent  the  enterprise’s  response  to  the  above  five  scenarios.  The  resultant  model 
contains  nineteen  (19)  processes  and  subprocesses  from  the  aerospace  strawman.  The  processes  and  sub¬ 
processes  encompassed  in  the  first  few  levels  of  development  of  that  strawman,  as  well  as  the  subset  selected  for 
inclusion  in  the  prototype  simulation  (shaded),  are  shown  in  Figure  L  The  schematic  diagram  of  the  simulation 
model  is  shown  in  Figure  Z  Almost  without  exception,  a  pair  of  information  flow  (or  product  flow)  'pipelines* 
are  used  to  interconnect  and  represent  the  clos^-loop  relationship  that  exists  between  pairs  of  iiueracting 
processes.  Thus,  for  example,  pipelines  1  and  2  represent  this  relationship  between  the  Customer  and  the 
program’s  highest  technology  process,  System  Engineering,  Similar  pairs  intercoimect  the  Customer  and 
Program  Management,  System  Engineering  and  Subsystem  Design,  and  so  forth.  Detailed  descriptions  of  the 
responsibilities  included  within  each  of  these  processes,  as  well  as  the  costing  nature  of  each,  is  pven  in  the 
material  that  follows. 

The  heavy  or  bold  pipelines  in  Figure  2  represent  busses  that  are  used  for  two  purposes.  The  first  is  to  repre¬ 
sent  multiple  inputs  are  summed  from  different  processes  for  delivery  to  another  process.  Examples  of  this  are 
the  accumulation  of  product  definition  products  from  a  half  dozen  processes  for  delivery  to  configuration 
management,  and  the  accumulation  of  finished  manufacturing  WIP  product  for  delivery  to  stores  and  the  build¬ 
ing  of  assembly  kits.  The  second  purpose  of  the  buss  is  for  representing  the  distribution  of  a  single  class  of  out- 
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FIGURE  2  -  SCHEMATIC  DIAGRAM  OF  THE  EIF  PROTOTYPE  SIMULATION  MODEL 


put  to  multiple  using  processes  of  that  output  Examples  of  this  are  the  distribution  of  processing  orders  by  the 
MRP  process  to  procurement,  stores,  and  manufacturing,  and  the  subsequent  distribution  of  production  kits  to 
the  various  manufacturing  tooling,  fabrication,  and  assembly  process  centers.  As  in  the  case  of  the  processes,  a 
brief  description  of  the  principal  content  of  each  of  these  pipelines  is  also  included  in  the  material  that  follows. 

The  aerospace  process  simulated  for  the  EIF  program  is  a  high  level  view  of  the  aerospace  design  and  produc¬ 
tion  processes  for  the  purpose  of  demonstrating  feasibility  rather  thaw  a  being  a  complete  process  model  used 
to  test  and  evaluate  program  alternatives.  The  development  of  a  complete  and  accurate  process  model  and  a 
full  simulation  of  the  of  all  variables  can  come  with  a  more  detailed  study  in  a  follow-on  contract.  In 

spite  of  the  fact  that  the  model  was  intended  to  oidy  demonstrate  feasibility,  the  authors  of  the  model  feel  that 
the  baseline  numbers  and  variables  are  reasonably  representative  of  reality  and  do  roughly  approximate  actual 
trends. 

For  the  purposes  of  demonstration,  the  assumptions  and  parameters  in  this  model  are  roughly  based  on  the 
Northrop  Aircraft  Dtvirion’s  experience  over  the  past  twenty  years  with  matmed  Cghters  for  the  Navy  and  Air 
Force.  Converting  the  process  model  to  another  firm  with  another  class  of  aircraft  would  require  research  into 
their  history  to  collect  d*»-tail«»d  data  on  such  rhing*  as  change  patterns  and  relationships  betw^  fabrication  and 
assembly  efforts  for  their  class  of  aircraft. 

The  process  model  is  controlled  by  varying  a  series  of  parameters  that  affect  the  outcome  of  the  simulation. 
The  parameters  be  grouped  into  three  fla<-<g-<-  The  first  class  is  for  customer  controlled  variables,  such  as 
production  rate.  The  second  are  the  prime  contractor  program  specific  variables  that  define  the  characteristics 
of  the  program  such  as  assembly  line  production  capacity.  The  third  are  the  prime  contractor’s  internal  environ¬ 
ment  variables  that  are  more  enterprise  driven  than  program  driven.  An  example  of  this  last  variable  is  the 
enterprise’s  ovuhead  burden  rate.  The  second  two  classes  of  parameters  define  the  characteristics  of  the  en¬ 
terprise  for  the  class  of  program  being  studied.  In  this  specific  instance,  the  second  two  classes  define  NAD’s 
experience  with  fighters.  The  three  classes  of  parameters  are  as  follows: 


Parameter  Class  1,  Customer  Controlled  Variables 
L  What  is  the  planned  production  life  of  the  aircraft? 

2.  What  is  the  planned  number  of  production  aircraft? 

3.  How  long  will  it  be  before  customer  requirements  mature  and  stabilize  where  no  customer  directed 
changes  are  implemented? 

Parameter  Class  II,  Prime  Contractor  ^iigram  Specific  Variables 
L  Will  concurrent  engineering  operations  be  applied  to  the  design  and  development  of  the  product? 

2.  What  percentage  of  program  that  will  be  subcontracted  to  major  subcontractors  and  suppliers? 

3.  Wbat  is  the  assembly  line  maximum  capacity  with  single  set  of  tools? 

4.  How  many  months  of  product  definition  effort  will  it  take  before  the  completion  of  the  first  production 
unit? 

5.  How  many  months  of  product  delivery  will  it  take  to  produce  an  aircraft? 

6.  Wbat  does  this  program  mean  to  the  enterprise  as  a  percentage  of  its  total  business? 
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Faruneter  CUu  Ill,  Trim  Contractor  Enterprise  Internal  Variables 


L  What  is  the  historical  distributioa  of  changes  per  year  from  all  smirces? 

Z  What  are  the  burden  rates  (both  fixed  and  variable  components)? 

3.  What  is  the  total  program  and  yearly  distribution  of  non-recurring  efforts  to  support  the  program? 

4.  What  is  the  historical  per  vehicle  cost  of  each  aircraft  for  those  activities  whose  epsts  are  ouly  inPnf-nr^/t 
by  the  quaiUity  of  airaaft? 


The  aerospace  process  model  addresses  the  interrelationslups  between  the  customer,  program  management, 
product  design,  implementation  planning,  and  production.  For  the  purposes  of  this  hi^  Imel  simulation,  the 
total  process  has  been  broken  down  into  nineteen  (sub)processes.  The  following  material  those 

nineteen  (sub)processes,  eqilains  their  responsibilities,  reviews  the  parameters  that  effect  the  cost  of  rarl'  of  the 
(sub)processes,  and  defines  the  primary  interprocess  relationships  (Le^  ‘pipelines*)  ideBtifiw/f  m  Figure  2. 


MODEL  (SUB)PROCESSES 

■  1.  Customer 

This  process  includes  all  of  the  customary  activities  normally  engaged  in  by  the  Department  of  Defense  or 
other  military  aircraft  customer.  This  includes  developing  mission  and  performance  profiles  and  require¬ 
ments,  soliciting  and  evaluating  bids  and  proposals,  reviewing  contracted  for  work,  ev^uating  and  approv¬ 
ing  deviations  and  change  requirements,  and  accepting  and  maintaining  delivered  products. 

There  is  no  cost  that  has  been  established  for  this  node  in  the  process.  Instead,  this  node  is  treated  as  a 
collection  point  for  customer  determined  parameters  such  as,  program  life  in  years,  total  production  quan¬ 
tity,  and  year  into  program  that  the  customer’s  requirements  will  be  stabilized. 


2.  Program  Management  and  Contracting 

This  process  mcludes  all  of  the  customary  activities  normally  engaged  in  by  the  program  and  contract 
management  personnel  assigned  to  a  military  aircraft  program.  This  includes  establis^g  and  enforcing 
program  policies  and  procedures,  maintaining  an  interface  with  the  customer,  managing  the  development 
of  company  proposals  associated  with  the  program,  chairing  the  various  change  and  configuration  review 
boards  that  evaluate  change  requests,  developing  and  maintaining  the  integrated  program  schedule, 
qualification,  solicitation,  and  selection  of  subcontractors,  and  support  of  the  technical  interface  between 
them  and  the  compan/s  development  personnel 

No  cost  has  been  determined  for  the  overhead  function  of  managing  the  program.  All  of  its  have 
been  treated  as  part  of  the  overhead  rate  used  for  all  of  the  other  nodes  in  the  total  process.  Instead,  this 
node  is  treated  as  a  coUeaion  point  for  prime  contractor  determined  parameters  such  as,  capacity  of  as¬ 
sembly  line,  overhead  rate,  and  program  costs  allocated  to  subcontractors. 


3.  System  Engineering 

This  process  includes  performance  of  the  airframe  weapon-system  level  analyses,  such  as  mission  and  per¬ 
formance  analyses,  overall  vulnerability,  reliability,  maintainability,  safety,  and  mass  properties  analyses.  It 
also  includes  coordination,  development,  and  negotiation  of  an  integrated  weapon  system  test  plan,  mclud- 
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ing  all  flight  test  planning  System  eogineeriag  is  also  responsible  for  the  deflnition  of  all  major  subsys¬ 
tems,  the  partitioning  of  weapon  system-level  requirements  into  subsystem  interface  and  performance  re¬ 
quirements,  and  the  integration  of  subsystem  design  into  the  Anal  weapon  system  configuration. 

System  ynginnnring  hss  both  a  non-recurring  and  a  recurring  component  with  the  non-recurcing  com¬ 
ponent  associated  with  the  initial  design  effort  and  the  recurring  component  a  function  of  the  level  of 
changes  over  the  production  life  of  the  program.  The  use  of  concurrent  engineering  principles  causes  a 
growth  in  the  level  of  effort  during  the  initial  design  effort  and  a  subsequent  decrease  as  the  reduced  level 
of  change  tninimiy^  the  recurring  sustaining  efforts. 


4.  Subsystem  Design 

This  process  includes  the  detailed  design  of  each  of  the  major  subsystems  into  which  the  weapon  system 
has  l^n  physically  and  functionally  subdivided.  These  include  the  vehicle’s  primary  structure,  the 
electronic  veUcle  control  and  maintenance  systems,  the  propulsion  system,  the  crew  systems,  the  environ¬ 
mental  system,  the  armament,  the  landing  and  arresting  gear,  and  the  secondary  power,  electrical,  and 
hydraulic  systems. 

Subsystem  Design,  like  System  En^eering,  has  both  a  non-recurring  and  a  recurring  component,  both  of 
which  behave  in  the  same  general  maimer  as  those  in  System  Engineering. 


5.  Subsystem  Design  Evaluation 

This  process  includes  both  the  functional  and  downstream  processing  evaluation  of  design  excellence,  nego¬ 
tiating  improvements  to  it  with  the  various  design  teams,  the  definition  of  requirements  for  supporting 
hardware,  electronics,  and  software  tools  and  equipment  needed  to  facilitate  product  manufacture  and 
maintenance,  and  the  development  of  detailed  processing  instructions  for  these  two  latter  activities.  Func¬ 
tional  evaluation  includes  both  analysis,  such  as  loading,  response,  mass  properties,  and  performance,  and 
developmental  and  proof  of  engineering  test,  including  wind  tuimel,  prototype,  and  bboratory  testing. 
Downstream  processing  analyses  include  product  produdbility,  testability,  inspectability,  procurement, 
and  logistics  support  analyses.  Support  tools  and  equipment  includes  production  and  inspection  tooling 
and  equipment,  handling  equipment,  storage  and  shipping  containers,  special  test  equipment,  and  field  sup¬ 
port  equipment.  Detailed  processing  instructions  indude  manufacturing  process,  inspection,  test,  procure¬ 
ment,  and  support  plaiming. 

Subsystem  Design  Evaluation,  like  System  Engineering,  has  both  a  non-recurring  and  a  recurring  com¬ 
ponent,  both  of  which  behave  in  the  same  general  manner  as  those  in  System  Engineering. 


6.  Auxiliary  Design 

This  process  indudes  the  design  of  production  and  inspection  tooling  and  all  the  spedal  test,  support,  han¬ 
dling,  storage,  and  shipping  equipment  whose  requirements  are  deflned  in  the  design  evaluation  steps. 
This  process  also  indudes  the  development  of  non-hardware  support  products  such  as  provisioning  parts 
lists,  technical  publications,  and  customer  training  materials. 

Auxiliary  Design,  like  System  Engineering,  has  both  a  non-recurring  and  a  recurring  component,  both  of 
which  behave  in  the  same  general  maimer  as  those  in  System  Engineering. 
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7.  Sabcontractor  Product  DefliiitloB 


This  process  includes  aD  the  design,  evaluation,  and  planning  activities  performed  by  the  sum  total  of  all 
the  program’s  subcontractors  who  have  design  responsibilities. 

Subcontractor  product  definition  is  controlled  by  a  combination  of  the  percentage  of  the  contract  per* 
formed  by  suppliers  and  the  percentage  of  the  suppliers  effort  where  the  supplier  has  design  responsibility. 
The  subcontractors  level  of  effort  is  further  controlled  by  the  prime  contractors  and/or  the  subcontractors 
nse  of  concurrent  engini»fffing  principles. 


S.  Configuration  Maiugement 

This  process  indudes  the  activities  performed  to  coordinate,  verify,  store,  and  disseminate  product  con¬ 
figuration  data  after  completion  of  product  definition.  It  is  also  responsible  for  maintaining  the  ”as-built* 
configuration  data  from  the  procurement,  fabrication,  and  assembly  records. 

Configuration  management’s  level  of  effort  is  directly  proportional  to  the  number  of  new  and  change  docu¬ 
ments  that  they  process.  The  number  of  change  documents  is  effected  by  concurrent  engineering  prin- 
dples  in  a  very  significant  way. 


9.  MRP  (Material  Requirements  Plannlog) 

This  process  indudes  development  of  production  gross  (based  solely  on  the  product’s  design  definition, 
production  schedule,  and  manufacturing  bill  of  materials)  and  net  (based  on  work  in  process,  material  in¬ 
ventory  status,  and  in-house  and  off-site  production  status)  resource  requirements,  production  capadty 
planning,  development  and  issuance  of  procurement  requisitions  and  shop  orders,  and  development  of  al¬ 
ternatives  to  production  plans  when  something  goes  wrong. 

MRP’s  planning  and  order  issuing  level  of  effort  is  influenced  by  level  of  production  and  the  number  of 
changes.  The  level  of  production  is  a  customer  driven  parameter  in  terms  of  the  quantity  of  airaaft 
produced  each  year.  The  number  of  changes  is  influenced  by  the  use  of  concurrent  engineering  principles. 


10.  Purchasing 

This  process  includes  qualification,  solidtation,  and  selection  of  suppUers,  negotiation  of  procurement 
terms  and  conditions,  issuance  of  purchase  orders,  and  tracking  of  procurement  and  off-site  manufactur¬ 
ing  status. 

The  cost  of  purchasing  is  influenced  by  the  level  of  production  and  the  number  of  design  changes. 


11.  Suppliers  Product  Delivery 

This  process  is  responsible  for  all  standard  parts,  raw  material,  and  manufacture  of  prime  contractor 
designed  parts  and  subassemblies.  In  support  of  this,  this  process  performs  all  manufacturing  resource 
planning,  procurement,  tooling,  fabrication,  assembly,  inspection,  and  test  processes. 

The  cost  of  material  provided  by  suppliers  is  influenced  by  the  percentage  of  the  contract  allocated  to  sup¬ 
pliers,  the  total  production  rate,  and  the  level  of  change  created  by  the  prime  contractor.  The  cost  of 
change  shows  up  in  the  cost  of  unneeded  material  and  scrap  when  the  change  makes  the  procured 
material’s  configuration  utmecessaiy. 
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12.  Subcontractors  Product  Delivery 

Tbis  process  is  responsible  for  the  production  of  all  parts  and  subassemblies  for  which  the  subcontractor 
has  design  responsibility.  In  support  of  this,  it  performs  all  manufacturing  resource  planning,  procure¬ 
ment,  tooling,  fabrication,  assembly,  inspection,  and  test  processes. 

The  cost  of  material  provided  by  subcontractors  is  influenced  by  the  percentage  of  the  contract  allocated 
to  subcontractors,  the  level  of  change  created  by  either  the  prime  contractor  and  subcontractor,  the  total 
production  rate,  and  improvement  in  prcducthity  as  a  result  of  assembly  experience  from  previous  units. 


23.  Receiving  and  Inspection 

This  process  includes  the  receipt  (log^g  in  and  cursory  veriGcation),  detailed  inspection  and  test,  accept¬ 
ance  or  rejection,  and  return  shipment  (where  applicable)  of  incoming  procurements. 

The  cost  of  receiving  and  inspection  is  influenced  by  the  total  production  rate  for  the  contract  and  the  level 
of  changes  created  by  Changes  result  in  reordering  of  material  that  became  scrap  as  a  result  of 

change  actions. 


14.  Stores  and  Kitting 

This  process  includes  all  warehousing  activities  associated  with  inventory  management,  including  storage, 
retrieval,  kitting,  dispersement,  status  accounting,  and  physical  cycle  counting  and  inventory  audits. 

The  cost  of  stores  and  kitting  is  influenced  by  the  total  production  rate  for  the  contract  and  the  level  of 
changes  aeated  by  design.  Changes  result  in  reordering  of  material,  additional  kits  to  rework  or  redo 
fabricated  items  and  assemblies.  The  level  of  changes  also  influences  the  required  frequency  to  analyze 
and  purge  excess  inventory. 

15.  Aujdliaiy  Designs'  Fabrication  and  Assembly 

This  process  includes  the  production  and  verification  of  manufacturing  tooling,  support  and  special  test 
equipment,  and  shipping  containers. 

The  cost  of  auxiliary  design  fabrication  and  assembly  is  influenced  by  the  total  production  rate  for  the  con¬ 
tract  and  the  level  of  changes  created  by  design.  When  changes  occur,  auxiliary  products  need  to  be 
reworked  or  remade. 


16.  Production  Batch  Manufacturing  (Fahricatlon) 

This  process  includes  the  batch  or  lot  production  (Le.,  one  set-up  per  production  lot)  of  all  fabricated  parts 
and  subassemblies  consumed  in  the  building  of  the  product.  It  includes  all  production  steps  and  proof  of 
manufacturing  tests  and  inspections. 

The  cost  of  production  batch  manufacturing  and  inspection  is  influenced  by  the  total  production  rate  for 
the  contract  and  the  level  of  change  created  by  design.  Changes  creates  rework  and  the  fabrication  of  re¬ 
placement  parts  for  parts  that  needed  to  be  scrapped. 
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17.  Pkvduction  Line  Flow  Manniactuiiag  (Assembly  Line) 

Tliis  process  includes  the  line  flow  production  Qx.,  one  tet*up  per  production  mn,  which  is  the  entire 
program  without  major  production  breaks)  for  all  subassembly,  assemblies,  and  installation  activities  made 
during  the  final  assembly  of  the  product  It  includes  all  production  steps  and  proof  of  manufacturing  tests 
and  inspections. 

The  cost  of  production  line  flow  manufacturing  is  influenced  by  the  level  of  change  created  by  design,  the 
total  production  rate,  and  improvement  in  producthity  as  a  result  of  assembly  eiperience  from  previous 
units. 


18.  Systems  Test 

This  process  includes  all  final  product  and  system  functional  testing  of  the  product  ^eluding  f%ht  testing) 
before  packagmg  (as  appropriate)  and  shipment  to  the  customer  site. 

The  cost  of  systems  test  is  influenced  by  the  level  of  change  created  by  design,  the  total  production  rate, 
and  improvement  in  productivity  as  a  result  of  experience  gained  from  testing  previous  units. 


19.  Packaging  and  Shipping 

This  process  includes  whatever  packaging  or  anting  is  required  to  prepare  deliverable  product  for  ship¬ 
ment  to  the  customer  sites.  This  activity  also  includes  any  inspections  of  the  results  of  the  activity,  as  ap¬ 
propriate. 

The  cost  of  packaging  and  shipping  is  influenced  by  the  level  of  change  aeated  by  the  total  produc¬ 

tion  rate,  and  improvement  in  productivity  as  a  result  of  experience  gained  from  packaging  previous  units. 


MODEL  (SUB)  PROCESS  RELATIONSHIPS  (!.«.,  PIPELINES) 


L  Informal  Technical  and  Trade  Study  Analysis  Results,  Review  Materials,  Proposals,  Technical  Recommen¬ 
dations,  and  Discussions 

2.  Program  Technical  (Mission,  Performance,  and  Environmental)  Requirements,  and  Technical  Review 
Results,  Requests,  Concerns,  and  Recommendations 

3.  Formal  Review  Materials  and  CDRL  Items,  Responses  to  RFIs  and  RFQs,  Proposals,  and  Approval  and 
Deviation/Waver  Requests 

4.  Program  (Business)  Requirements,  Requested  Program  (Business  and  Technical)  Requirements  Changes, 
Formal  Review  Results  and  Approvals  for  Requested  Deviations  and 

5.  Program  Configuration  Management  Plan 

6.  Trade  Study  Analysis  Results,  Technical  Proposals,  and  Technical  Development  Status  and  Problems 

7.  Program  Poh'des  and  Directives,  Technical  Development  Budgets  and  Schedules,  Change  Review  Board 
Requests  and  Decisions 
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8.  Muagemeat  Manufacturiiig  Resource,  Process,  aad  Risk  Decisions 

9.  RFIs,  RFQs,  Counterproposals  and  Negotiations,  and  Subcontracts 

10.  Formal  Configuration  Change  Requests  and  Proposals 

IL  Subcontractor(s)  Product  Information,  and  Proposals 

12.  Proposed  Production  Plans  and  Resource  Allocations 

13.  Subsystem(s)  (Working  and  Releaseable)  Designs,  Information,  Problems,  Interface  and  Performance 
Requirement  Change  Requests,  Subsystem(s)  Trade  Study  Analysis  Results,  and  Change  Impact  Analysis; 
Results 

14.  Partitioned  SubcyBtem(t)  Responsibilitiet  (Mission,  Performance,  Environmental,  and  Subcyttem(s)  Inter* 
face  Requirements) 

15.  Weapon  System  Analysis  Results  and  Test  Plans,  and  Integrated  Weapon  System  Configuration(s),  includ¬ 
ing  the  Integrated  Weapon  System  Indentured  Parts  list 

16.  Subsys(em(s}  Design  Geometry,  Parts  lists.  Unit  Test  Specs,  and  Product  Functional  Specs  (for  Sub¬ 
contracting 

17.  Released  Product  Definition 

18.  Recommended  or  Needed  Design  Refinements/Changes, 

19.  Subsystem(s)  Working  and  Releaseable  Design  Geometry,  Intended  and  Implemented  Design  Changes 

20.  Subsystem(s)  Working  and  Releaseable  Design  Geometry 

2L  Implementation  (Production,  Process,  Inspection,  Test,  Support,  and  Packaging)  Plans  and  Instructions, 
Logistics  Support  Analysis,  Numerical  Control  (Production  and  Inspection)  Programs,  Manufaauring 
Bill(s)  of  Material,  Make  or  Buy  Decisions,  and  Functional  and  Qualification  Test  Reports,  Implementa¬ 
tion  Plan  and  NC  Program  Changes 

22.  Tooling  Policy  and  Requirements  Problems  and  Recommendations,  Support  and  Special  Test  Equipment 
Requirement  Problems  and  Recommendations 

23.  Tooling  Policy  and  Requirements,  Support  and  Special  Test  Equipment  Requirements,  Customer  Training 
Requirements,  and  Technical  Publications  Requirements 

24.  Subcontractor(s)  Design  Recommendations,  (Workmg  and  Releaseable)  Designs,  Subsystem(s)  Interface 
Problems,  and  Trade  Study  Analysis  Results 

25.  Tool,  Support,  Special  Test  Equipment,  and  Packaging  Designs  and  Part  Lists,  Provisioning  Parts  Lists, 
Customer  Training  Program(s),  and  Tooling  and  Auxiliary  Equipment  Design  Changes 

26.  Subsystem(s)  Working  and  Releaseable  Design  and  Concepts,  Unit  Interface  Requirements,  Product  Func¬ 
tional  Specs,  and  (Interface  and  Functional)  Design  Requirement  Changes 

27.  Subcontractor(s)  Product  Definition 

28.  Subcontractor(s)  Design  Definition 
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29.  Coatract  Delivery  Requirements  (Schedule  and  Production  Rates),  Subcontracting  and  Ofl-Loading  Re¬ 
quirements,  and  integrated  Program  Schedules 

30.  Coordinated,  Release  Product  Definition  and  Changes 
3L  Product  Delivery  Status 

32.  Procurement  and  Outside  Manufacturing  (Subcontractors  and  Suppliers)  Status 

33.  Purchase  Requisitions  (with  Relevant  Product  Definition) 

34.  Supplier(s)  Product  Delivery  Status  and  Problems 

35.  Solidtatioas,  Inquiries,  and  Purchase  Orders  (anth  Relevant  Product  Definition) 

36.  Rejected  (and  Returned)  Supplier(s)  Shipments 

37.  Subcontractor(s)  Product  Delivery  Status  and  Problems 

38.  Rejected  (and  Returned)  Subcontractor(s)  Shipments 

39.  Delivered  Shipments,  Test  Samples,  and  Reworked  Procurements 

40.  Delivered  Shipments,  Test  Samples,  and  Reworked  Procurements 

41.  Rejected  Incoming  Shipments 

42.  In-House  Inventory,  Work-in-Process,  and  Production  Status  and  Problems 

43.  Verified  and  Accepted  Shipments 

44.  Completed  Fabricated  Parts,  Assemblies,  and  Tools 

45.  Raw  Materials,  Tools,  and  Work-In-Process  Kits 

46.  Shop  Orders  and  Relevant  Product  Definition 

47.  Requested  Batch  Manufactured  Product  and  Tooling  Configuration  Changes 

48.  Requested  Line  Flow  Manufactured  Product  and  Tooling  Configuration 

49.  Unshipable  Final  Products 

50.  Finished  Product 

5L  Determine  Product  Performance  and  Production  Quality  Defidendes  and  Deviations 
52.  Verified  Product 
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assumptions 


A  Bumber  of  assumptions  had  to  be  made  to  permit  the  degree  of  amplification  needed  to  rapidly  create  algo¬ 
rithms  that  reasonably  represented  complex  enterprise  behavior  for  the  abstract  form  of  model  developed.  The 

principal  assumptions  made  in  designing  the  simulation  prototype  were: 

L  Concurrent  can  be  simply  and  accurately  simulated  through  a  reduction  in  the  number  of 

post-design  completion  that  have  to  be  procetfed  after  initiation  of  implementation  plaxming,  tool¬ 

ing  development,  subcontractor  development  processes,  issuance  of  procurement  contracts,  and  in-house 
production.  In  other  words,  concurrent  engineering  could  be  simply  represented  by  the  reduction  in 
change  processing  labor  costs,  both  in  design  and  all  of  the  other  affected  'downstream'  processes.  This 
assumption  neglects  to  for  time-wise  or  partial  implementations  of  the  many  aspects  of  concurrent. 

which  Can  be  accounted  for  through  the  selection  of  more  conservative  values  for  the  percent¬ 
age  of  and  hence,  of  rework  reduction.  There  was  not  simple  way,  however,  developed  or  included 

to  account  for  the  smoother  running,  more  cffident  operations  that  would  result  in  the  reduced  change 
processing  environmenL  For  the  most  part,  the  accounting  for  any  scrappage  reduction  due  to  a  cor¬ 
responding  change  reduction  is  made  through  the  reduced  product  delivery  efforts  and  costs  of  the 
company's  subcontractors  and  suppliers. 

2.  The  implementation  of  concurrent  engineering  at  any  percentage  of  company  subcontractors  can  be  simply 
and  accurately  simulated  by  applying  the  same  cost  reduction  factors  determined  for  in-house  implementa¬ 
tion  to  that  percentage  of  outside  work  also  subjected  to  such  an  implementation. 

3.  A  production  rate  change  can  be  simply  and  accurately  simulated  by  redistributing  the  fixed  portion  of  busi¬ 
ness  and  program  cost  (Le.,  the  non-recurring  process  costs  plus  the  non-variable  portion  of  recurring 
costs,  such  as  facilities  and  equipment,  tooling,  insurance,  and  so  forth)  over  the  smaller  number  of  units 
to  be  produced. 

4.  A  significant  break  in  production  activities  could  be  simply  and  accurately  simulated  by  reinitiation  of  the 
learning  'experience*  of  direct  labor  persoimel  assigned  to  the  production  activities.  In  addition,  in  some 
cases,  where  the  break  was  to  be  treated  as  so  major  as  to  require  reassignment  or  attrition  of  the  other¬ 
wise  constant  line  flow  production  resources  (facilities,  equipment,  tooling,  and  personnel),  the  simulation 
would  be  more  appropriately  modeled  with  the  fixed  cost  of  what  is  effectively  the  construction  of  a  new 
start-up  facility,  induding  the  acquisition  and  indoctrination  of  new  employees  to  replace  those  lost  during 
the  interruption.  Because  each  case  would  be  unique,  no  provision  is  made  for  application  of  significant 
penalty  costs  to  be  paid  to  either  the  prime  or  subcontractors  due  to  the  interruption. 

5.  Instability  in  customer  stated  requirements  (Le.,  customer  directed  changes  to  contract  and  product  re¬ 
quirements)  could  be  simply  and  accurately  simulated  requiring  a  percentage  redoing  of  both  product 
definition  (at  the  prime  and  all  subcontractors)  and,  depending  on  the  timing  of  required  changes,  product 
deUvery.  The  percentage  of  redoing  of  each  would  be  different  due  to  the  different  times  of  initiation  and 
duration  of  the  two  major  processes.  As  in  the  case  of  concurrent  engineering,  the  accounting  for  any 
scrappage  increases  due  to  the  introduction  of  additional  change  is  made  through  the  increased  product 
delivery  efforts  and  costs  of  the  company’s  subcontractors  and  suppliers. 
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FINDINGS 


The  conclusioiu  reached  as  a  result  of  the  simulation  prototyping  efforts  have  been  reached  from  a  combination 
of  actual  experience  and  the  research  into  the  work  ^  oth«  that  has  been  extracted  from  the  literature  .  In 
general,  these  Rnrfing*  gre: 

1.  High-level,  management-type  nmnlation  modeling  of  complex  manufacturing  enterprises  can  effectively  be 

performed  m  a  top-down  manner,  vdierein  high-level  undecomposed)  processes  can  be  simply 
described  and  cause  and  effect  relationships  can  be  easily  modeled  usiag  simplified  algorithms  that  express 
the  results  of  changes  rather  how  the  changed  processes  work  or  how  the  dianges  are  implemented. 

2.  More  complex  and  accurate  models  can  be  evolved  from  these  high-level  models  through  decomposition, 
of  the  high  level  processes,  and  continued  research  into  and  more  precise  understanding  of  the  cause  and 
effect  relationships  between  process  stimuli  and  enterprise  and  process  performance. 

3.  A  number  of  existing  eommerdally  available  language  packages  appear  to  have  aD  the  necessary 
capabilities  to  perform  complex  manufacturing  enterprise  simulations;  however,  all  contain  their  own  lan¬ 
guage  peculiarities  and  would  require  a  different  implementation  of  the  same  EIF  developed  industry 
■standard*  process  and  technology  descriptions. 

4.  The  relatively  simple,  high-level  management-type  simulations  can  be  performed  on  relatively  small  desk¬ 
top  type  of  computers  or  workstations;  however,  as  such  models  are  e:^anded  to  accommodate  more 
de^^  simulations  to  satisfy  new  process  design  development  users,  it  is  unlikely  that  such  would  con¬ 
tinued  to  be  the  case.  This  could  require  transition  to  use  of  large  mainffames  on  which  to  perform  very 
(time-wise)  lengthy  computations,  or  would  require  partitioning  and  integration  of  smaller  models  used  to 
simulated  only  portions  of  enterprise  processes. 

5.  The  easiest  part  of  performing  complex  enterprise  and  process  simulation  is  the  construction  of  the  model 
on  the  Emulation  tool  By  far  the  more  challenging,  time  consnmmg,  and  costly  part  of  the  task  mvolves 
first,  study  and  understanding  of  the  complex  cause  and  effect  relationships  that  actually  exist  in  such  en¬ 
terprise  operations;  second,  the  design  of  the  simulation  model  to  accurately  and,  as  simply  as  possible,  al¬ 
gorithmically  represent  these  relationships;  and  finally,  the  compiling  of  accurate,  discrete  sUdstics 
metrics)  from  enterprise  historical  and  current  operations  records  with  which  to  populate  the  designed 
model  This  latter  step  may,  in  fact,  be  the  most  difficult  of  ail 

^Belardo.  S.  and  Weinrnth.  J_  Simulation  in  Business  and  Management.  Volume  2L  Number  4.  The  Sodetv  for 
G>mputer  Simulation,  San  Diego,  California,  January  1990. 

Feller,  AJA^  Troject  Management  Through  Simulation*,  Proceedings  of  4th  Annual  Procurement  Research 
SvniD<^ium.  October  1975. 

Xetcham,  M.G.  Shannon,  R.E.,  and  Hogg,  GX.,  Information  Structures  for  Simulation  Modeling  of  Manufac¬ 
turing  Systems',  Simulation.  February  1989. 

Xiran,  A.S.,  Schloffer,  A.,  and  Hawkins,  D.,  ”An  Integrated  Simulation  Approach  to  Design  of  Flexible  Manufac¬ 
turing  Systems*,  Simulation.  February  1989. 

I  L.,  Badiru,  A.,  Foote,  BX.,  Ravindran,  A.,  and  Williams,  L.,  'Job  Shop  Configuration  Optimization  at 
Tinker  Air  Force  Base*,  Simulation.  June  1990. 

Log/An,  Inc.  (Company  Report),  *Project  Risk  Assessment  and  Management  wath  PROMAP  V. 

Salgame,  R.R.,  Becker,  S.G.,  and  Yu,  D.H.,  *SPARKS;  A  Knowledge  Based  Process  Modeling  and  Simulation 
System*,  Coopers  and  Lybrand,  Decision  Support  Group,  Center  for  Manufacturing  Technology. 
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KECOMMENDATIONS 


The  development  of  the  managemeDt'Ievel  prototype  shows  much  promise  in  being  tble  to  effectively  simulate 
and  project  enterprise  performance  for  critical  business  and  program  decision  malting  snppoxl.  The  modeling 
done  thus  far,  however,  only  scratches  the  surface,  even  insofar  as  demonstrating  feasibility  is  conocmed.  For 
example,  only  the  on  cost  have  been  included,  and  yet  those  on  schedule  and  output  or  product  quahty 
are  equally  important  in  helping  managers  make  informed  decisions.  Therefore,  the  following  recommendations 
are  made  for  further  EIF  relat^  simulation  studies: 

L  Continue  the  development  of  the  management-level  prototype,  expanding  it  to  indude  development 
schedule,  product  quality,  resource  requirements  effects,  and  a  much  broader  range  of  management  criti¬ 
cal  scenarios.  These  would  mdude  the  effects  of  subcontract  structure  (i'^n  terms  and  conditions),  the. 
quality  of  product  fimctional  specifications  applied  to  such  subcontracts,  the  failure  of  the  prime  or  sub¬ 
contractors’  products  to  meet  any  of  their  respective  functional  obligations,  and  so  forth. 

2.  Determine  the  effective  limits  of  management-type  simulations  on  commercially  available  software  based 
on  small  computers,  such  as  personal  and  desk  top  computers. 

3.  Support  the  development  and  industry  acceptance  of  a  "standard*  simulation  language  that  would  permit 
portability  of  EIF  timulation  and  model  development  results  to  potential  users  throughout  the  united 
States  manufacturing  industry;  the  QM-OSA  standard,  already  under  development  for  use  in  the 
European  manufacturing  community,  would  be  an  appropriate  and  recommended  vehicle  for  such  develop¬ 
ment 

4.  Eiqiand  the  development  of  the  management-level  model  to  the  greater  depth  required  to  support  process 
analysis,  design,  and  implementation  by  decomposing  the  EIF  aerospace  processes  from  one  to  two  or 
more,  as  found  appropriate,  levels  of  detail,  including  development  of  the  greater  number  of  process  (or 
subprocess,  as  the  will  be)  relationships  and  algorithms  to  mathematically  represent  these  relation¬ 
ships.  Such  detail  should  include  such  factors  as  the  impacts  of  personnel  skill  mix,  funding  profile,  man¬ 
power  loading,  task  definition,  task  initiation  and  completion  criteria,  facility,  equipment,  tool  capabilities, 
level  and  effectiveness  of  process  and  subprocess  control,  level  of  required  documentation,  and  the  like. 
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